Re: Volume allocated to *MASTER*

[PINION, RICHARD W.]

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, November 3, 2021 1:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Volume allocated to *MASTER*

[External Email. Exercise caution when clicking links or opening attachments.]

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 
about how to actually do this :)

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of kekronbekron
> Sent: Tuesday, November 02, 2021 10:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Volume allocated to *MASTER*
>
> 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 ‐‐‐
>
> On Wednesday, November 3rd, 2021 at 10:35 AM, Seymour J Metz 
>  wrote:
>
> > 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.
> >
> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on
> behalf of kekronbekron 02dee3fcae33-dmarc- requ...@listserv.ua.edu
> >
> > Sent: Tuesday, November 2, 2021 11:49 PM
> >
> > To: IBM-MAIN@LISTSERV.UA.EDU
> >
> > Subject: Re: Volume allocated to MASTER
> >
> > 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
> sme...@gmu.edu wrote:
> >
> > > Run the TIOT in the Master address and see what is allocated/
> > >
> > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on
> behalf of PINION, RICHARD W. rpin...@firsthorizon.com
> > >
> > > Sent: Tuesday, November 2, 2021 10:21 AM
> > >
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > >
> > > Subject: Volume allocated to MASTER
> > >
> > > 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 against MASTER, and none of the
> > >
> > > datasets listed are on the volume in question.
> > >
> > > Confidentiality notice:
> > >
> > > This e-mail message, including any attachments, may contain 
> > > legally
> privileged and/or confidential information. If you are not the 
> intended recipient(s), or the employee or agent responsible for 
> delivery of this message to the intended recipient(s), you are hereby 
> notified that any dissemination, distribution, or copying of this 
> e-mail message is strictly prohibited. If you have received this 
> message in error, please immediately notify the sender and delete this e-mail 
> message from your computer.
> > >
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > >
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-
> MAIN
> > >
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > >
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-
> MAIN
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
> >
> > 
> > ---
> -
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access 

Re: Volume allocated to *MASTER*

[Gibney, Dave]

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 
about how to actually do this :)

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of kekronbekron
> Sent: Tuesday, November 02, 2021 10:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Volume allocated to *MASTER*
> 
> 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 ‐‐‐
> 
> On Wednesday, November 3rd, 2021 at 10:35 AM, Seymour J Metz
>  wrote:
> 
> > 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.
> >
> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on
> behalf of kekronbekron 02dee3fcae33-dmarc-
> requ...@listserv.ua.edu
> >
> > Sent: Tuesday, November 2, 2021 11:49 PM
> >
> > To: IBM-MAIN@LISTSERV.UA.EDU
> >
> > Subject: Re: Volume allocated to MASTER
> >
> > 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
> sme...@gmu.edu wrote:
> >
> > > Run the TIOT in the Master address and see what is allocated/
> > >
> > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on
> behalf of PINION, RICHARD W. rpin...@firsthorizon.com
> > >
> > > Sent: Tuesday, November 2, 2021 10:21 AM
> > >
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > >
> > > Subject: Volume allocated to MASTER
> > >
> > > 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 against MASTER, and none of the
> > >
> > > datasets listed are on the volume in question.
> > >
> > > Confidentiality notice:
> > >
> > > This e-mail message, including any attachments, may contain legally
> privileged and/or confidential information. If you are not the intended
> recipient(s), or the employee or agent responsible for delivery of this
> message to the intended recipient(s), you are hereby notified that any
> dissemination, distribution, or copying of this e-mail message is strictly
> prohibited. If you have received this message in error, please immediately
> notify the sender and delete this e-mail message from your computer.
> > >
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > >
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-
> MAIN
> > >
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > >
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-
> MAIN
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > ---
> -
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Volume allocated to *MASTER*

[kekronbekron]

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 ‐‐‐

On Wednesday, November 3rd, 2021 at 10:35 AM, Seymour J Metz  
wrote:

> 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.
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of 
> kekronbekron 02dee3fcae33-dmarc-requ...@listserv.ua.edu
>
> Sent: Tuesday, November 2, 2021 11:49 PM
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: Re: Volume allocated to MASTER
>
> 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 sme...@gmu.edu 
> wrote:
>
> > Run the TIOT in the Master address and see what is allocated/
> >
> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of 
> > PINION, RICHARD W. rpin...@firsthorizon.com
> >
> > Sent: Tuesday, November 2, 2021 10:21 AM
> >
> > To: IBM-MAIN@LISTSERV.UA.EDU
> >
> > Subject: Volume allocated to MASTER
> >
> > 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 against MASTER, and none of the
> >
> > datasets listed are on the volume in question.
> >
> > Confidentiality notice:
> >
> > This e-mail message, including any attachments, may contain legally 
> > privileged and/or confidential information. If you are not the intended 
> > recipient(s), or the employee or agent responsible for delivery of this 
> > message to the intended recipient(s), you are hereby notified that any 
> > dissemination, distribution, or copying of this e-mail message is strictly 
> > prohibited. If you have received this message in error, please immediately 
> > notify the sender and delete this e-mail message from your computer.
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Reliable source for slang term "noodle picker"?

[Seymour J Metz]

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 picker.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, November 2, 2021 10:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reliable source for slang term "noodle picker"?

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 stumbled on a mention in a Redbook (remember Redbooks?):
ZE11
System z and Storage Synergy
Scott Drummond s...@us.ibm.com
18 - 20 September, 2012 IBM Forum Brussels

I may have fumbled away the URL.  Perhaps:
https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwit94_zlPvzAhVBlGoFHbbFDMQQFnoECAoQAQ=ftp%3A%2F%2Fwww.redbooks.ibm.com%2Fredbooks%2F2012_ITSO_Total_Solution_Event_System_z_Brussels%2Ftrack_03_New_Technologies_on_zEnterprise%2FZE11_%2520System_z_and_Storage_Synergy_September_11_2012.pdf=AOvVaw1dHbjFmr4HYw8kOEqcDPod

Ugh!  Google Tracker!

Or: 

(But is that Shmuel's  own article?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Volume allocated to *MASTER*

[Seymour J Metz]

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.


From: IBM Mainframe Discussion List  on behalf of 
kekronbekron <02dee3fcae33-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, November 2, 2021 11:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Volume allocated to *MASTER*

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 is allocated/
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of 
> PINION, RICHARD W. rpin...@firsthorizon.com
>
> Sent: Tuesday, November 2, 2021 10:21 AM
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: Volume allocated to MASTER
>
> 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 against MASTER, and none of the
>
> datasets listed are on the volume in question.
>
> Confidentiality notice:
>
> This e-mail message, including any attachments, may contain legally 
> privileged and/or confidential information. If you are not the intended 
> recipient(s), or the employee or agent responsible for delivery of this 
> message to the intended recipient(s), you are hereby notified that any 
> dissemination, distribution, or copying of this e-mail message is strictly 
> prohibited. If you have received this message in error, please immediately 
> notify the sender and delete this e-mail message from your computer.
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler analysis

[kekronbekron]

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 PM, Jared Hunter 
 wrote:

> 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 well-commented the original ASM is, the right application of 
> disassembly to graphs, giant displays, and coffee* might get you to 
> high-quality supportable HLL faster than inspecting/converting the original 
> source.
>
> -Jared
>
> Jared Hunter
>
> Director of Software Engineering, Z Security
>
> Rocket Software
>
> 77 Fourth Avenue • Waltham, MA 02451 • USA
>
> t: +1 781 684 2162 • m: +1 617 821 3745 • e: 
> jhunter@rs.commailto:jhun...@rs.com • he / him / his
>
> Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ 
> Main Office Toll Free Number: +1 855.577.4323
>
> Contact Customer Support: 
> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
>
> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
> http://www.rocketsoftware.com/manage-your-email-preferences
>
> Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
> 
>
> This communication and any attachments may contain confidential information 
> of Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
> prohibited. If you are not the intended recipient, please notify Rocket 
> Software immediately and destroy all copies of this communication. Thank you.
>
> -
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Volume allocated to *MASTER*

[kekronbekron]

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 is allocated/
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of 
> PINION, RICHARD W. rpin...@firsthorizon.com
>
> Sent: Tuesday, November 2, 2021 10:21 AM
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: Volume allocated to MASTER
>
> 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 against MASTER, and none of the
>
> datasets listed are on the volume in question.
>
> Confidentiality notice:
>
> This e-mail message, including any attachments, may contain legally 
> privileged and/or confidential information. If you are not the intended 
> recipient(s), or the employee or agent responsible for delivery of this 
> message to the intended recipient(s), you are hereby notified that any 
> dissemination, distribution, or copying of this e-mail message is strictly 
> prohibited. If you have received this message in error, please immediately 
> notify the sender and delete this e-mail message from your computer.
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Reliable source for slang term "noodle picker"?

[Paul Gilmartin]

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 stumbled on a mention in a Redbook (remember Redbooks?):
ZE11
System z and Storage Synergy
Scott Drummond s...@us.ibm.com
18 - 20 September, 2012 IBM Forum Brussels

I may have fumbled away the URL.  Perhaps:
https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwit94_zlPvzAhVBlGoFHbbFDMQQFnoECAoQAQ=ftp%3A%2F%2Fwww.redbooks.ibm.com%2Fredbooks%2F2012_ITSO_Total_Solution_Event_System_z_Brussels%2Ftrack_03_New_Technologies_on_zEnterprise%2FZE11_%2520System_z_and_Storage_Synergy_September_11_2012.pdf=AOvVaw1dHbjFmr4HYw8kOEqcDPod

Ugh!  Google Tracker!

Or: 
(But is that Shmuel's  own article?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Reliable source for slang term "noodle picker"?

[Seymour J Metz]

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, November 2, 2021 6:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reliable source for slang term "noodle picker"?

 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 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.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[CM Poncelet]

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 Earth's center, the slower too is the Earth's rotation (as per
the conservation of angular momentum).
 

On 02/11/2021 19:46, Mike Schwab wrote:
> 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 after 50 years of precise measuring, so
> estimating a leap second every year after 150 years and 1 second every
> day in 54,000 years.
>
> A Mars day is 24:37:00.  People working with various Mars probes
> arrive 37 minutes later each day since their work arrives from Mars at
> that time.  At least they don't get the jet lag when you have to
> change shifts by 8 hours over a weekend.
>
> On Tue, Nov 2, 2021 at 4:33 PM Alan Altmark  wrote:
>> 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.  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 doesn't pause, repeat, or go 
>> backwards. How an OS translates that concept into its local clock is left an 
>> exercise to the vendor.
>>
>> Alan Altmark
>> IBM
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Reliable source for slang term "noodle picker"?

[Ed Jaffe]

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 access. On a 
multivolume data set, each extent could be on a different device.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Reliable source for slang term "noodle picker"?

[Warren Brown]

 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 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.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Reliable source for slang term "noodle picker"?

[Seymour J Metz]

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 "noodle picker"?

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.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Reliable source for slang term "noodle picker"?

[Phil Smith III]

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.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Volume allocated to *MASTER*

[Allan Staller]

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 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Volume allocated to *MASTER*

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

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 against *MASTER*, and none of the datasets listed are on 
the volume in question.
Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Mike Schwab]

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 after 50 years of precise measuring, so
estimating a leap second every year after 150 years and 1 second every
day in 54,000 years.

A Mars day is 24:37:00.  People working with various Mars probes
arrive 37 minutes later each day since their work arrives from Mars at
that time.  At least they don't get the jet lag when you have to
change shifts by 8 hours over a weekend.

On Tue, Nov 2, 2021 at 4:33 PM Alan Altmark  wrote:
>
> 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.  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 doesn't pause, repeat, or go backwards. 
> How an OS translates that concept into its local clock is left an exercise to 
> the vendor.
>
> Alan Altmark
> IBM
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Variable length records for SYSIN data sets

[Paul Gilmartin]

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 record?  Is this documented?

I believe I once caused an error by lengthening a record by substitution, even
though the increased length was still less than the value of the DD LRECL 
option.
Reported to SR;  Got WAD.  That may have been before some of the APARs
you mentioned.

Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: formatting help

[Paul Gilmartin]

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)?
Perhaps even a solution or circumvention for Joseph, Eric, et al.?

>I will send an example right behind this one. (This is from an ancient Outlook 
>running on Windows.)
> 
I see it.

Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Variable length records for SYSIN data sets

[Paul Gilmartin]

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 JES2 and JES3 work differently.  
>
Thanks.  I had neglected to check the JES hooks,  But the JCL Ref. for "DD *" 
amd
"DD DATA" ought to include citations of that JES passage.

An omission I discovered by experiment which should be documented:
If no record exceeds 80 bytes (even if lengths differ),
attributes will be RECFM=FB,LRECL=80.

>But bottom line, for JES2, everything is based on the actual length of each 
>record written.  This gets a little tricky with TSO SUBMIT (or ISPF SUBMIT) 
>commands.  SUBMIT always writes records with a record length of 80.  So all 
>instream data sets are RECFM F and LRECL 80 when SUBMIT is involved.  For 
>other uses of the internal reader, as already stated, the RECFM is F if all 
>records are the same length (including if there are 0 or 1 records).  If the 
>lengths of the record vary, the RECFM is V.  CC is supported if the JCL 
>(records) are written with CC (eg using IEBGENER from a RECFM VBM data set) 
>and the RECFM is adjusted accordingly (fun rules for if there are both ASA and 
>machine CC).
>   
That "fun rule" ought to be documented.  Your second citation says,
" ... If both ASA and Machine carriage control are detected, the record format 
will be set in the RECFM."
It ought to show RECFM=what?

>Instream data set LRECL for RECFM F data sets is the length of the records.  
>If there are 0 records (null data set), it is the length of the DD * or DD 
>DATA card (very old rule).  For RECFM V data sets, the LRECL is set to the 
>length of the longest record in the instream data.  
>
ITYM 4 + the length of the longest record.

Very terrible "very old rule"  Is it documented?

>Note for all of this, each instream data set is processed separately.  So each 
>data set can have a different LRECL/RECFM.
>
Is that documented?

>As for LRECL on the DD * or DD DATA card, JES2 ignored this until APAR 
>OA60172.  Starting with that APAR, if an instream data set is RECFM F and 
>LRECL is specified, JES2 will pad records for the data set up to the LRECL 
>specified.  This helps when using instream data concatenated to other RECFM F 
>data sets.
>
>This is not to say that LRECL was totally ignored on a DD * or DD DATA card.  
>When the DCB access method is used to read an instream data set (vs ACB/RPLs), 
>the size of the buffer the access method passes to JES is determined by the 
>LRECL specified on the DD.  Also note that in a concatenation, the RECFM is 
>determined by the first DD in the concatenation.  A customer trying to 
>concatenate a RECFM V data set to a RECFM F instream data set with LRECL 
>specified led to APAR OA62088.  You see the fix for APAR OA60172 added too 
>much padding to an instream data set.  Basically, LRECL on the instream DD 
>statement in that case included the 4 byte RDW prefix but the ACB/RPL 
>interface passes the actual length so padding to LRECL made the record 4 bytes 
>too long.
>
>Hopefully this enlightens a bit on how all this works.

I submitted an RCF yesterday.

>Tom
>JES2 Development

Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Paul Gilmartin]

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 doesn't pause, repeat, or go backwards. 
>How an OS translates that concept into its local clock is left an exercise to 
>the vendor.
> 
I stand corrected.  And my Linux will actually display 23:59:60 if I set
TZ=right/...

z/OS shirks the issue by making user address spaces non- dispatchable
during a leap second.  z/VM?

I have seen some discussion of inserting leap seconds at 23:59:60 local
time rather than UTC.  Bad Idea.

I have entertained the idea of making the Fall DST transition at midnight
so the inserted hour could be represented unambiguously as
24:00:00 to 24:59:59.  No enthusiastic support.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Variable length records for SYSIN data sets

[Tom Wasik]

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 JES2, everything is based on the actual length of each 
record written.  This gets a little tricky with TSO SUBMIT (or ISPF SUBMIT) 
commands.  SUBMIT always writes records with a record length of 80.  So all 
instream data sets are RECFM F and LRECL 80 when SUBMIT is involved.  For other 
uses of the internal reader, as already stated, the RECFM is F if all records 
are the same length (including if there are 0 or 1 records).  If the lengths of 
the record vary, the RECFM is V.  CC is supported if the JCL (records) are 
written with CC (eg using IEBGENER from a RECFM VBM data set) and the RECFM is 
adjusted accordingly (fun rules for if there are both ASA and machine CC).
  
Instream data set LRECL for RECFM F data sets is the length of the records.  If 
there are 0 records (null data set), it is the length of the DD * or DD DATA 
card (very old rule).  For RECFM V data sets, the LRECL is set to the length of 
the longest record in the instream data.  

Note for all of this, each instream data set is processed separately.  So each 
data set can have a different LRECL/RECFM.

As for LRECL on the DD * or DD DATA card, JES2 ignored this until APAR OA60172. 
 Starting with that APAR, if an instream data set is RECFM F and LRECL is 
specified, JES2 will pad records for the data set up to the LRECL specified.  
This helps when using instream data concatenated to other RECFM F data sets.

This is not to say that LRECL was totally ignored on a DD * or DD DATA card.  
When the DCB access method is used to read an instream data set (vs ACB/RPLs), 
the size of the buffer the access method passes to JES is determined by the 
LRECL specified on the DD.  Also note that in a concatenation, the RECFM is 
determined by the first DD in the concatenation.  A customer trying to 
concatenate a RECFM V data set to a RECFM F instream data set with LRECL 
specified led to APAR OA62088.  You see the fix for APAR OA60172 added too much 
padding to an instream data set.  Basically, LRECL on the instream DD statement 
in that case included the 4 byte RDW prefix but the ACB/RPL interface passes 
the actual length so padding to LRECL made the record 4 bytes too long.

Hopefully this enlightens a bit on how all this works.

Tom
JES2 Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: formatting help

[Charles Mills]

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  
(GMT-08:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: formatting help 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 03:48:36 +, Eric D 
Rossman,was similarly adversely flowed.  I haven't recognized any commonality.I 
have a Rexx program which uses the SDSF API to fetch *all* spoolfiles of a job 
into different members, job/step/procstep/dd of a tempOMVS directory and "pax 
-wzf //some.data.set .">    ... and plop it onto an easily>accessible site 
(examples:  DropBox, Google Drive) and post the link>in your message on this 
forum.  It keeps your message on the forum>simple plain text and it would be 
very easy for those of us willing>to try to help you to do just that.-- 
gil--For 
IBM-MAIN subscribe / signoff / archive access instructions,send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: formatting help

[Charles Mills]

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 Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, November 2, 2021 9:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: formatting help

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 03:48:36 +, Eric D 
Rossman,
was similarly adversely flowed.  I haven't recognized any commonality.

I have a Rexx program which uses the SDSF API to fetch *all* spool
files of a job into different members, job/step/procstep/dd of a temp
OMVS directory and "pax -wzf //some.data.set ."

>... and plop it onto an easily
>accessible site (examples:  DropBox, Google Drive) and post the link
>in your message on this forum.  It keeps your message on the forum
>simple plain text and it would be very easy for those of us willing
>to try to help you to do just that.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Alan Altmark]

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.  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 doesn't pause, repeat, or go backwards. 
How an OS translates that concept into its local clock is left an exercise to 
the vendor.

Alan Altmark
IBM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler analysis

[Farley, Peter x23353]

"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 to see 
the supported formats.

https://hex-rays.com/ida-free/

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jared Hunter
Sent: Tuesday, November 2, 2021 12:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler analysis

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://urldefense.com/v3/__https://hex-rays.com/products/ida/processors/__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!fCPnQqD7ahDjkSjrciR0XuPzceQUm6ssXuagIxsJ67MiRHYtk5qTsgK0HXGjJviD7spjsg$
 

Depending on how well-commented the original ASM is, the right application of 
disassembly to graphs, giant displays, and coffee* might get you to 
high-quality supportable HLL faster than inspecting/converting the original 
source.

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler analysis

[Jared Hunter]

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 well-commented the original ASM is, the right application of 
disassembly to graphs, giant displays, and coffee* might get you to 
high-quality supportable HLL faster than inspecting/converting the original 
source.

-Jared

Jared Hunter
Director of Software Engineering, Z Security
Rocket Software
77 Fourth Avenue • Waltham, MA 02451 • USA
t: +1 781 684 2162 •  m: +1 617 821 3745 • e: 
jhun...@rs.com • he / him / his


Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: formatting help

[Paul Gilmartin]

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 03:48:36 +, Eric D 
Rossman,
was similarly adversely flowed.  I haven't recognized any commonality.

I have a Rexx program which uses the SDSF API to fetch *all* spool
files of a job into different members, job/step/procstep/dd of a temp
OMVS directory and "pax -wzf //some.data.set ."

>... and plop it onto an easily
>accessible site (examples:  DropBox, Google Drive) and post the link
>in your message on this forum.  It keeps your message on the forum
>simple plain text and it would be very easy for those of us willing
>to try to help you to do just that.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: formatting help

[Bob Raicer]

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 keeps your message on the forum
simple plain text and it would be very easy for those of us willing
to try to help you to do just that.

Bob

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Volume allocated to *MASTER*

[PINION, RICHARD W.]

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 an SETPROG unallocate, and
bounced LLA.  At that point, XCFAS and LLA released the volume.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Tuesday, November 2, 2021 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Volume allocated to *MASTER*

[External Email. Exercise caution when clicking links or opening attachments.]

Are there any interesting datasets on the volume?

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://urldefense.com/v3/__https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.com__;!!HnnddUIWDII9UQ!E2gIeHNsu3Tw0cV8It8sNFZ_fSXki-eFkGbvm5FjII5Kn0Qlfrwb1h2l7Mnc6HO1cT0$

‐‐‐ Original Message ‐‐‐

On Tuesday, November 2nd, 2021 at 10:21 AM, PINION, RICHARD W. 
 wrote:

> 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 against MASTER, and none of the
>
> datasets listed are on the volume in question.
>
> Confidentiality notice:
>
> This e-mail message, including any attachments, may contain legally 
> privileged and/or confidential information. If you are not the intended 
> recipient(s), or the employee or agent responsible for delivery of this 
> message to the intended recipient(s), you are hereby notified that any 
> dissemination, distribution, or copying of this e-mail message is strictly 
> prohibited. If you have received this message in error, please immediately 
> notify the sender and delete this e-mail message from your computer.
>
> --
> --
> --
> --
> --
> --
> --
> --
> --
> --
> --
> --
> -
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Volume allocated to *MASTER*

[Seymour J Metz]

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 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 against *MASTER*, and none of the
datasets listed are on the volume in question.
Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Volume allocated to *MASTER*

[Mark Jacobs]

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 W. 
 wrote:

> 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 against MASTER, and none of the
>
> datasets listed are on the volume in question.
>
> Confidentiality notice:
>
> This e-mail message, including any attachments, may contain legally 
> privileged and/or confidential information. If you are not the intended 
> recipient(s), or the employee or agent responsible for delivery of this 
> message to the intended recipient(s), you are hereby notified that any 
> dissemination, distribution, or copying of this e-mail message is strictly 
> prohibited. If you have received this message in error, please immediately 
> notify the sender and delete this e-mail message from your computer.
>
> -
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Volume allocated to *MASTER*

[PINION, RICHARD W.]

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 against *MASTER*, and none of the
datasets listed are on the volume in question.
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[Stefan Skoglund]

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.
> 
> -- gil
> 
> -
> -
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-
> MAIN

my point was that UTC doesnt change one whole hour in a leap.

Ie in the spring this happends :

UTC   CET   CST
00:59:58  01:59:58   -
00:59:59  01:59:59   -
01:00:00   -03:00:00
01:00:01   -03:00:01

and now this saturday night (early morning 31 Oct) :
00:59:58   -02:59:58
00:59:59   -02:59:59
01:00:00   02:00:00   -
01:00:01   02:00:01   -

'-'  Now we don't use this time zone except in the case of the clock in
 the building belongin to an association i'm a member of (very few
 of us was in that building between 1 jan this year until now in
 september so that clock showed swedish normal time all the summer,
 but now it shows the time everyone here expect a clock to show -
 automagic)

and oh yeah the time magicians (ie astronoms) adjust UTC using a
leap second.

IF two different people in different timezones installs each their own
z15,  if they push return at exactly the same time. What time
will the HMC expect the computer to be in ? (sort of.)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Data Exfiltration

[Lennie Dymoke-Bradshaw]

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 November 2021 12:10
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Data Exfiltration

"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 nibbles and drive the screen using a 
>script. Slow but doable.
> 
Yale ASCII IUP?

Kermit?  
Not HTTPS!  1995.

IIRC, these rely on a degeneracy mapping control sequences to 6-bit characters.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fall back STP Adjustments

[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.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Data Exfiltration

[Paul Gilmartin]

"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 nibbles and drive the screen using a 
>script. Slow but doable.
> 
Yale ASCII IUP?

Kermit?  
Not HTTPS!  1995.

IIRC, these rely on a degeneracy mapping control sequences to 6-bit characters.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Assembler analysis [was: RE: Serverpac installs January 2022 and beyond - Issues]

[Allan Staller]

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 
beyond - Issues]

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

There Aint No Such Thing As A Free Lunch - The Moon Is A Harsh Mistress.

On Mon, Nov 1, 2021 at 8:30 PM Allan Staller 
<0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:
>
> Classification: Confidential
>
> ITYM TANSTAAFL, as originally coined by Larry Niven(?)
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Farley, Peter x23353
> Sent: Monday, November 1, 2021 11:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Assembler analysis [was: RE: Serverpac installs January 
> 2022 and beyond - Issues]
>
> [CAUTION: This Email is from outside the Organization. Unless you 
> trust the sender, Don’t click links or open attachments as it may be a 
> Phishing email, which can steal your Information and compromise your 
> Computer.]
>
> I am aware of only one product (commercial) that claims to be of any help in 
> language conversion for assembler code, but there may be more of which I am 
> unaware.  In the one case I am aware of, the results were truly horrible 
> COBOL code that didn't even come close to performing the same function as the 
> assembler from which it was converted.  I will not name the product for 
> obvious reasons.
>
> In my experience of performing this exact task more than once in my career, I 
> have found that the best route to success is deep reading of the assembler 
> code until you understand the function, input, and output criteria.  Once you 
> understand what it is supposed to accomplish, rewriting it manually in a more 
> "modern" language is far more likely to succeed than any mechanical 
> conversion can provide for you.
>
> TANSTAFL -- There ain't no such thing as a free lunch.  You have to put in 
> the effort to understand the original code or you are probably not going to 
> get it right.
>
> If you are lucky there is some kind of programmer-level or at least 
> business-level documentation available describing the original intended 
> function along with its expected inputs and outputs.  If not, the only choice 
> left is just reading and understanding the code on your own.
>
> Good luck.  It can be quite a hard task, but if you put in the effort you can 
> succeed.
>
> Peter
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Warren Brown
> Sent: Monday, November 1, 2021 12:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Serverpac installs January 2022 and beyond - Issues
>
> Hey experts;  I am back with mainframes.  I have a new position to 
> analyze to  assembly language program. Is their any programs to 
> analyze ASM programs for re-write them to a more modern language. 
> Perhaps their are tools to help me, Thanks, Warren
> --
>
>
>
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> ::DISCLAIMER::
> 
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses 
> in transmission. The e mail and its contents (with or without referred 
> errors) shall therefore not attach any liability on the originator or HCL or 
> its affiliates. Views or opinions, if any, presented in this email are solely 
> those of the author and may not necessarily reflect the views or opinions of 
> HCL or its affiliates. Any form of reproduction, dissemination, copying, 
> disclosure, modification, distribution and / or publication of this message 
> without the prior written consent of authorized representative of HCL is 
> strictly prohibited. If you have received this email in error please delete 
> it and notify the sender 

Re: Fall back STP Adjustments

[Stefan Skoglund]

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 time of transition, either CST is correct (or maybe neither
> > are).
> > 
> I'm more comfortable with the opposite convention:
>     06:59:59.999... UTC is 01:59:59.999... CDT
>     07:00:00.000... UTC is 01:00:00.000... CST
> 
> Works better rounding to integral seconds.

but this is bonkers. UTC never changes, it increases monotonically and
it doesn't jump back or forward.

My own timezone is CET so as soon as this weekend we go from CST to
CET, but the time in Greenwich doesnt jump. What society does is
changing the offset between it's employed wall clock time ie between 31
october and in April England uses UTC as local wall clock time and
changes to and fro Western European Summer Time.

Which means that this weekend we had 02:59:59 two times in the same
night (sort of)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN