We have BMC's Mainview, and one can issue the TIOT command for
a particular address space. I ran the command for *MASTER*, and
there were no allocations for the volume in question.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Gibney, Dave
Sent: Wednesday,
The original issue was "Why is *MASTER* holding a volume?"
So, yes the suggestion is to dump (or look live if you have the tools) and the
TIOT in *MASTER* looking for entries pointing to the volume and determine the
dataset being held. I've never needed to do this, so don't ask me any more
Thanks for the brief on what the TIOT is (which I could have looked up).
However, I don't understand what you mean by 'run the TIOT in the master
address space'.
Do you mean to dump some address space, and then look for a specific data area
with IPCS or some such?
- KB
‐‐‐ Original Message
I'm not the editor, but if you click on the second URL, you should see "view
history" at the top of the page. Look for the most recent October 29, 2021
update and click on previous. That will show you the change in question.
As previously noted, it was stuffer that was deleted rather than
The Task I/O Table is a control block that lists all of the allocations for a
jobstep. There is an entry for each allocated dataset, and each entry contains
the relevant UCB addresses. If you're already familiar with the DSAB chain, you
could search that instead.
Also check out https://www.capstone-engine.org/ plus a few of its related
projects, such as Unicorn, Keystone, etc.
I remember seeing (in their slides) IBM itself sponsoring or working on this
too, w.r.t the Z parts.
- KB
‐‐‐ Original Message ‐‐‐
On Tuesday, November 2nd, 2021 at 9:36
Hi Seymour,
For someone who doesn't understand (me), can you please elaborate what you mean
by 'run the TIOT in the master address space'.
- KB
‐‐‐ Original Message ‐‐‐
On Tuesday, November 2nd, 2021 at 8:02 PM, Seymour J Metz
wrote:
> Run the TIOT in the Master address and see what
On Fri, 29 Oct 2021 19:45:37 +, Seymour J Metz wrote:
>One of the wiki editors has removed mention of the term "noodle picker" from
>[[IBM 2321 Data Cell]] with the explanation "Really remove unreferenced OR".
>Does anybody have a reliaible source for this usage that I can cite?
>
I
No, no and no.
There were direct access storage devices in the 1950s.
MBBCCHHR is not the address that goes over the channel.
M applies to all DASD, not just the 2321.
From: IBM Mainframe Discussion List on behalf of
Warren Brown
Sent: Tuesday,
AFAIK The time of the Earth's rotation is not a constant, but is subject
to the variable position of its inner iron-core relative to the Earth's
geometric center. The closer this inner iron-core is to the Earth's
center, the faster too is the Earth's rotation - else, the further it is
from the
On 11/2/2021 3:13 PM, Warren Brown wrote:
Noodle picker is the grand daddy of DASD it you at DASD address you'l see
MBBCCHHRR THE first characters NBB are good for noodle picker only.
I thought only BB were used for picking noodles.
M is still by DASD to indicate which extent you wish to
Noodle picker is the grand daddy of DASD it you at DASD address you'l see
MBBCCHHRR THE first characters NBB are good for noodle picker only. On
Tuesday, November 2, 2021, 06:02:31 PM EDT, Phil Smith III
wrote:
I of course understand Wikipedia's desire for citation, but in cases
No, if challenged you need a citation with claims about colloquial usage.
From: IBM Mainframe Discussion List on behalf of
Phil Smith III
Sent: Tuesday, November 2, 2021 6:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reliable source for slang term
I of course understand Wikipedia's desire for citation, but in cases like
this it's probably just not possible.
Would it maybe pass muster if it says something like "colloquially known as
the 'noodle picker'"? That makes it clearer that it's not official and
perhaps unverifiable.
Classification: Confidential
Check for a lnklisted dataset on the volume( possibly added dynamically).
SETPROG LNKLST, update,JOB(*) (syntax?)
D U,alloc,ucbaddr,1
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
PINION, RICHARD W.
Sent: Tuesday, November 2, 2021
And I think adding a second inside a minute is a mistake. Seconds
00-59, Minutes 00-59, Length of day dependends on the planet. An
Earth Day is usually 24:00.00 but can vary to 23:59:59 or 24:00:01,
used to be about 11 hours 4 Billion years ago. Earth days seem to be
longer by 1/3 of a second
On Tue, 2 Nov 2021 11:39:17 -0500, Tom Wasik wrote:
>
> For RECFM V data sets, the LRECL is set to the length of the longest
> record in the instream data.
>
Is that the length before or after SYMBOLS= substitution? What happens if
substitution
increases the length of that longest
On Tue, 2 Nov 2021 09:33:28 -0700, Charles Mills wrote:
>Everything I write from my Samsung e-mail clients is similarly flowed. We
>kicked this around a couple of months ago. @Phil Smith analyzed what exactly
>was happening.
>
Can you supply details or a citation (List; Date; Subject; or URL)?
On Tue, 2 Nov 2021 11:39:17 -0500, Tom Wasik wrote:
>How the internal reader handles instream data sets is documented here:
>https://www.ibm.com/docs/en/zos/2.4.0?topic=reader-record-length-sysin-data-sets
>https://www.ibm.com/docs/en/zos/2.4.0?topic=reader-sysin-record-formats
>Also note that
On Tue, 2 Nov 2021 11:33:17 -0500, Alan Altmark wrote:
>>>
>>... UTC falls back at a leap second.
>
>Nope. There is no fall back for leap seconds. They are *inserted* into the
>time stream (Temporal Mechanics 101). When that happens, UTC goes from
>11:59:59 to 11:59:60 to 00:00:00. It
How the internal reader handles instream data sets is documented here:
https://www.ibm.com/docs/en/zos/2.4.0?topic=reader-record-length-sysin-data-sets
https://www.ibm.com/docs/en/zos/2.4.0?topic=reader-sysin-record-formats
Also note that JES2 and JES3 work differently.
But bottom line, for
Sent from Samsung Android email client and probably will be mangled. Looks good
on the client before I hit Send! CharlesSent from a mobile; please excuse the
brevity.
Original message From: Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> Date: 11/2/21 9:05 AM
Everything I write from my Samsung e-mail clients is similarly flowed. We
kicked this around a couple of months ago. @Phil Smith analyzed what exactly
was happening.
I will send an example right behind this one. (This is from an ancient Outlook
running on Windows.)
Charles
-Original
On Tue, 2 Nov 2021 07:51:00 -0500, Paul Gilmartin wrote:
>On Tue, 2 Nov 2021 11:46:56 +0100, Stefan Skoglund wrote:
>>
>>... UTC never changes, it increases monotonically ...
>>
>Those two statements contradict each other. And both are
>incorrect. UTC falls back at a leap second.
Nope.
"Supported", yes, but very likely only useful for zLinux binaries. The
"supported file formats" on the url below only list "PE, ELF, Mach-O" as
supported formats. z/OS executable formats (load module, program object) are
not listed at all. Scroll down to the product version comparison table
Peter wrote:
> TANSTAFL -- There ain't no such thing as a free lunch. You have to put in the
> effort to understand the original code
This, but with a twist.
zArchitecture (s390 and s390x) are listed as supported by IDA Pro.
https://hex-rays.com/products/ida/processors/
Depending on how
Hi, Bob,
On Tue, 2 Nov 2021 09:45:03 -0600, Bob Raicer wrote:
>How about putting your assembler listing file, your job log, and any
>other relevant (perhaps annotated) info into a single file (a zip
>file as a container would be fine)
>
One other ply, this morrning from On Tue, 2 Nov 2021
How about putting your assembler listing file, your job log, and any
other relevant (perhaps annotated) info into a single file (a zip
file as a container would be fine) and plop it onto an easily
accessible site (examples: DropBox, Google Drive) and post the link
in your message on this forum.
It is a cloned RES volume. All of the datasets for our RES volumes
are cataloged to '**'. When XCFAS and LLA were using that
volume, we discovered two datasets in the link list which were
cataloged to the volser. We updated the catalog entries for those
datasets, rebuilt the link list, did
Run the TIOT in the Master address and see what is allocated/
From: IBM Mainframe Discussion List on behalf of
PINION, RICHARD W.
Sent: Tuesday, November 2, 2021 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Volume allocated to *MASTER*
We are running
Are there any interesting datasets on the volume?
Mark Jacobs
Sent from ProtonMail, Swiss-based encrypted email.
GPG Public Key -
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
‐‐‐ Original Message ‐‐‐
On Tuesday, November 2nd, 2021 at 10:21 AM, PINION, RICHARD
We are running z/OS 2.2. We have a volume that is allocated
to *MASTER*. Originally, the volume was allocated to XCFAS
LLA, and *MASTER*. We got XCFAS and LLA to release their
allocations by updating the link list. However, we cannot
determine what *MASTER* is holding.
I've used SDSF's JD
tis 2021-11-02 klockan 07:51 -0500 skrev Paul Gilmartin:
> On Tue, 2 Nov 2021 11:46:56 +0100, Stefan Skoglund wrote:
> >
> > ... UTC never changes, it increases monotonically ...
> >
> Those two statements contradict each other. And both are
> incorrect. UTC falls back at a leap second.
>
Not sure how this matter migrated to IBM-MAIN.
It is an ongoing discussion on RACF-L.
Lennie Dymoke-Bradshaw
https://rsclweb.com
‘Dance like no one is watching. Encrypt like everyone is.’
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Gilmartin
Sent: 02
On Tue, 2 Nov 2021 11:46:56 +0100, Stefan Skoglund wrote:
>
>... UTC never changes, it increases monotonically ...
>
Those two statements contradict each other. And both are
incorrect. UTC falls back at a leap second.
-- gil
"Re: ..."? This appears to be a followup with no original article.
On Mon, 1 Nov 2021 22:35:05 -0400, Phil Smith III wrote:
>...
>If I were [more?] evil and wanted to exfiltrate data on a system where
>IND$FILE was disabled/removed, I'd do as others have
>suggested: convert the data to hex
Classification: Confidential
Thanks for the correction
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Mike Schwab
Sent: Monday, November 1, 2021 3:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler analysis [was: RE: Serverpac installs January 2022 and
mån 2021-11-01 klockan 15:09 -0500 skrev Paul Gilmartin:
> On Mon, 1 Nov 2021 12:19:31 -0700, Retired Mainframer wrote:
>
> > I think the answer is both. AT 0700 UTC it will be 0200 CDT.
> > After an
> > infinitely small interval, it will still be 0700 UTC but will be
> > 0100 CST. At
> > the
38 matches
Mail list logo
