I've never tried what you're looking to do. We don't share data across sysplex
boundaries. It might annoy your users, but you might try giving them a
different userid on each system. Each userid would have its own unique access
rights even though it represents the same person.
Now that I
On 20/07/2018 12:38 AM, Thomas David Rivers wrote:
David Crayford wrote:
It's always best to get storage on the stack and avoid the heap if
you can. z/OS C/C++ supports the GCC extensions that allow you to
align storage using
variable attributes.
char buffer[1408]
Good point,
I'll do that. It should have occurred to me that it was more appropriate there.
Brian
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO
You may get an answer on this listserv, but might also have better luck with
the RACF listserv... https://listserv.uga.edu/cgi-bin/wa?A0=RACF-L
HTH,
Mike
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Brian Westerman
Sent:
Hi,
I was hit with a question that I don't know the answer to. Previously (until
today) I had thought, but never tried, that you could have a shared RACF
database between two LPARs and that you could protect datasets differently
based on the DATASET class rule such that if you had a dataset
I've not seen any official mention of this, so I figured I'd make an unofficial
mention of it.
The IBM Toolkit for Swift on z/OS Community Edition has been released by IBM.
It's a free download (don't know if that will change). More information can be
found here:
On Thu, 19 Jul 2018 12:38:06 -0400, Thomas David Rivers David Crayford wrote:
>
>I don't think LE allows the stack to be above-the-bar
XPLINK-64 allocates the stack above the bar. I don't know if that can be
overridden.
--
Tom Marchant
If you haven't had a chance to share your thoughts with us, we'd love to
hear from you! We'd appreciate your response by July 20, 2018.
Thanks to everyone who has taken our survey to date.
Please take our survey to help us understand any time consuming or complex
tasks that you experience with
David Crayford wrote:
It's always best to get storage on the stack and avoid the heap if you
can. z/OS C/C++ supports the GCC extensions that allow you to align
storage using
variable attributes.
char buffer[1408] __attribute__((__aligned__(16))) ; // only works in
64-bit
Unless the
Done, although he's too nice of a person to have to keep explaining the
inexplicable. :-)
sas
On Thu, Jul 19, 2018 at 11:23 AM, Charles Mills wrote:
> So NILF takes -16 but NILL won't take -4?
>
> You should post that on the HLASM list. Jonathon Scott of HLASM
> development is very responsive
You get OPERLOG recording not just 'if' JES2 is down. OPERLOG starts recording
very early in an IPL--before JES starts--and continues until V XCF,OFF--after
JES has shut down. SYSLOG can eventually write out very early IPL-time messages
stored by MVS before JES starts but quits as soon as JES
Glen,
Do you have a CFRM CDS defined to a monoplex environment, what for ?
When you list LOGR definitons, are they ok ? (DATA TYPE(LOGR) REPORT(YES) )
Atenciosamente / Regards / Saludos
Ituriel do Nascimento Neto
BANCO BRADESCO S.A.
4250 / DITI Engenharia de Software
Sistemas Operacionais
So NILF takes -16 but NILL won't take -4?
You should post that on the HLASM list. Jonathon Scott of HLASM development is
very responsive there.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Smith
Sent: Thursday,
Thank-you Mr. Relson!
Oddly enough, in rerunning my test, it seems that it fails considerably
less than half the time. That is, it usually aligns on a 16-byte
boundary. This test version is configured to allocate the cpool anchor and
extent, plus four 160-byte buffers. This is to stress-test
"that is all the SYSLOGs that are being collected all in one place, right?"
If you mean: "all SYSLOGs within the Sysplex" you are right. Logstreams don't
cross sysplexes.
Unfortunately, we don't use IEAMDBLG, so I can't help you there.
We still use the jes2 syslog for daily archiving, no
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: 19 July, 2018 15:22
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSLOG and LOGR query
>
> On Thu, Jul 19, 2018 at 8:20 AM Vernooij, Kees (ITOPT1) - KLM <
>
OK, I understand Allan's point about there being no benefit in using CFs
with DASDONLY, but I'd put that consideration to one side since - as I say
- I'm working with a MONOPLEX and so I don't expect to be sharing anything.
I just want to make use of the facility.
I've already put a fair amount
On Thu, Jul 19, 2018 at 8:20 AM Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:
> He says he has a monoplex.
> The advantage is, that you het syslog data in the operlog logstream,
> i.s.o. Jes2 Sysout files. That can be easier to process, search, keep for a
> longer period etc.
>
He says he has a monoplex.
The advantage is, that you het syslog data in the operlog logstream, i.s.o.
Jes2 Sysout files. That can be easier to process, search, keep for a longer
period etc.
Kees.
> -Original Message-
> From: IBM Mainframe Discussion List
" dasd only logstreams don't need a CF structure" - Agreed.
However the logstream cannot be shared.
If OPERLOG is established on 2 separate systems they cannot operate
concurrently and use the same logstream, so what is the benefit?
-Original Message-
From: IBM Mainframe Discussion
2 things that may help:
- dasd only logstreams don't need a CF structure
- you can browse the operlog via SDSF and the LOG O command. This way you can
verify that Operlog works and you can concentrate on retrieving it.
Grtn,
Kees.
> -Original Message-
> From: IBM Mainframe Discussion
DASD only logstreams cannot be shared. Architectural limitation.
You can get operlog to work w/DASDONLY, but only for a single system.
There is no benefit to LOGR unless you have a CF.
To save you the work, don't bother w/SMF or LOGREC logstreams either.
HTH,
-Original Message-
I'm trying to use a LOGR logstream to gather the SYSLOG data, but I don't
appear to be able to make it work...
I believe I've correctly followed all the instructions detailed in the
relevant section of the "z/OS System Logger" redbook.
Modifying the CFRM policy to add the OPERLOG structure, and
> Problems:
> 1. Undocumented requirement to quad-word align CPOOL anchor and/or
extent
> in 64-bit mode (and actually undocumented alignment requirements for
all).
> 2. Unable to guarantee quad-word alignment with malloc.
I will get the first taken care of. The anchor does not need to be
I'm pretty sure I hit the same problem.
Silly question, but you do have the coexistence SPE on your system?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the
25 matches
Mail list logo
