Re: PoOP z/ARCH latest xx number

[Joe Monk]

I dont see any J mnemonics in the PoOP.
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf

They are documented in the HLASM guide:
https://publibz.boulder.ibm.com/epubs/pdf/asmr1021.pdf on page 67

They are also documented in the z/Arch Reference Summary:
https://www.ibm.com/support/pages/sites/default/files/2021-05/SA22-7871-10.pdf
on page 42

Joe

On Fri, Sep 20, 2024 at 10:06 AM Wayne Driscoll <
05791921711d-dmarc-requ...@listserv.ua.edu> wrote:

> Keep in mind that the Jxx instructions are "extended mnemonics" the actual
> instructions are BRC (Branch Relative Conditional) and documented as that.
> Wayne Driscoll
> Broadcom MSD
> All opinions are strictly my own
>
> On Fri, Sep 20, 2024 at 9:39 AM Ramsey Hallman <
> 061e76a747b5-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Steve,
> >
> > I believe the most recent is -13 ( Fourteenth Edition (May, 2022) - First
> > Edition being 00).
> >
> > The Jump mnuemonics are definitely in that edition.
> >
> > Ramsey
> >
> > On Fri, Sep 20, 2024 at 9:27 AM Steve Thompson  wrote:
> >
> > > I am trying to get an up to date copy of the PoOP and when I
> > > check it for "J" instructions, I'm not finding them.
> > >
> > > Is this because those really only exist in HLASM?
> > >
> > > Certain instructions, I haven't used in years and wanted to make
> > > sure they work, within reason (32 regs to 64 bit regs) as I
> > > remembered.
> > > --
> > >
> > > Regards,
> > > Steve Thompson
> > >
> > > --
> > > 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
> >
>
>
> --
> Wayne Driscoll
> Software Engineer | Mainframe Software Division
> Broadcom Software
>
> *Office: *630-300-1931* Mobile:* 630-310-1784
> wayne.drisc...@broadcom.com
>
> --
> This electronic communication and the information and any files
> transmitted
> with it, or attached to it, are confidential and are intended solely for
> the use of the individual or entity to whom it is addressed and may
> contain
> information that is confidential, legally privileged, protected by privacy
> laws, or otherwise restricted from disclosure to anyone else. If you are
> not the intended recipient or the person responsible for delivering the
> e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.
>
> --
> 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: Preserving RDW for VB Files in CA XCOM Transfers from z/OS to Linux

[Joe Monk]

It all depends whether the receiving system supports VB files.

Joe

On Sun, Aug 18, 2024 at 7:27 PM Jason Cai  wrote:

> Hi all
>
>  We need to transfer a large number of Variable Blocked (VB) format files
> from z/OS to Linux systems while maintaining the Record Descriptor Word
> (RDW) intact.
> Previously, using z/OS FTP, we achieved this with the bin command and
> locsite RDW. We are now considering using CA XCOM for data transfer.
>   Has anyone successfully preserved the RDW of VB files when transferring
> from z/OS to Linux using CA XCOM? Does CA XCOM have a feature similar to
> FTP for preserving RDW?
>  Any suggestions or assistance would be greatly appreciated.
> Thank you,
>
> Jason  Cai
>
> --
> 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: Does MVCDK move 'per byte' like MVC?

[Joe Monk]

"Therefore, the length in bytes
of each operand is 1-256, corresponding to a length
code in L of 0-255."

For a move less than 256 bytes, I think it is always byte-by-byte.

Joe

On Fri, Jul 26, 2024 at 1:44 PM Erik Janssen <
062c999269e8-dmarc-requ...@listserv.ua.edu> wrote:

> Hello All,
>
> I had this code in a user SVC:
>  MVI   DATA,X'40' BLANK OUT DATA
>  MVC   DATA+1(254),DATA
>
> As far as I'm aware this is a well known principle to clear a data area,
> it is explained in the POP under MVC that you can propagate a byte this way.
>
> Since the DATA area is provided by the caller of the user SVC I
> implemented this code to do the same with MVCDK to make sure the protection
> key of the storage area matches the callers key (in R1). The 'spatie' field
> is defined as 'SPATIE   DCCL1' '
>
>  LHI   R0,L'SPATIE-1
>  MVCDK DATA,SPATIEBLANK OUT DATA
>  LHI   R0,L'DATA-2MOVE 254 CHARS
>  MVCDK DATA+1,DATA
>
> I had assumed that MVCDK would also propagate a byte this way and tested
> this on a ZD&T machine and that seemed to work ok.
>
> Now that we have this code on our test lpar on a z16 machine I see that it
> will shift the full contents of the DATA field one position to the right.
> This causes residual data from the previous call to appear.
>
> The POP says under MVCDK:
> Each of the operands is processed left to right.
> When the operands overlap destructively in real storage, the results in
> the first-operand location are
> unpredictable. Except for this unpredictability in the
> case of destructive overlap, the storage-operandconsistency rules are the
> same as for the MOVE
> (MVC) instruction
>
> Did I encounter that unpredictability the POP is talking about? Is it
> possible that on a ZD&T MVCDK works byte for byte like MVC, while on real
> hardware MVCDK works more like a MVCL moving all the bytes at once? And, if
> MVCDK does not work a byte at a time, what would be a correct solution for
> this? Copy a byte at a time with MVCDK in a loop, like the programming
> example in the POP with the MVCSK instruction?
>
> Kind regards,
> Erik Janssen.
>
>
> --
> 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: World’s largest computer outage!

[Joe Monk]

Plus, there's a side benefit to using cash. It retains its value.

"Real dollars — cash — have a set of qualities that are hard to replicate
in a digital currency. Cash is universally accessible, universally
accepted, relatively stable in value, and can be exchanged for goods and
services without transaction fees. And it lends itself to privacy,
anonymity, and free expression."

Joe

On Fri, Jul 19, 2024 at 11:27 PM Paul Edwards <
0676ab6435a5-dmarc-requ...@listserv.ua.edu> wrote:

> On Sat, 20 Jul 2024 13:04:00 +1000, Wayne Bickerdike 
> wrote:
>
> >*Are you suggesting using physical cash because software andhardware
> >engineers are unable to create a reliable alternative?*
> >
> >Absolutely yes. There are myriad reasons, in my case I have a pension paid
> >into a UK account. Domiciled in Australia it's the best way for me to
> >access these funds and have cash.
> >
> >In Australia there's a push to cashless, however, lots of businesses have
> >suffered through similar outages and are going back to cash. EFTPOS is a
> >cash cow for banks and network providers of ATMs.
>
> It may seem like a "cash cow", but you need to weigh up the cost
> of that electronic infrastructure vs the cost of the entire process
> of chopping down trees to making cash and humans counting
> the cash etc etc. Those costs are basically being hidden. Maybe
> they exceed the cost of the "cash cow" and if it is an economic
> question, then the government should pay those banks etc
> directly for taking pressure off the physical cash infrastructure
> and lost productivity.
>
> Basically I find it hard to believe that we (hardware and software
> engineers) can't construct something more cost-effective and
> even reliable than using dead trees. If we are tasked with doing
> such a thing. And if we are given budget to fix bugs instead of
> only being given a budget to add new features. And include the
> cost of physical cash being lost - perhaps in a house fire - or
> wallets being lost/stolen. And perhaps include the cost of the
> drug trade being facilitated (assuming that is a factor).
>
> >The PC would be fine
>
> Oh - let's start here. You envisage a solution. I'd like to hear it.
>
> > if it wasn't trying to do everything and had a myriad
> >of vulnerabilities in the registry and installation and update processes.
>
> So - what specifically needs to be done to eliminate this issue?
> Someone mentioned OS/2 as a possible solution. I will mention
> that PDOS and its supporting toolchain exists - not necessarily a
> solution. Definitely not as sophisticated as OS/2. But that's not
> necessarily a bad thing. It may or may not be a bad thing - it's
> an open question I have. We have a tangible problem. One instance
> of it, anyway. And I saw a couple of people here suggesting that the
> mainframe was the solution. It may or may not be - open question.
>
> BFN. Paul.
>
> --
> 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: World’s largest computer outage!

[Joe Monk]

"Can you elaborate on this? Who made the decision to require
admin rights?"

Software developers using the registry to store things. Any software
install on a Windows PC requires admin rights to write certain values to
the registry.

Linux does not suffer from these issues, nor does macOS.

"Can you elaborate on this too - how did external kids get
involved in administering your PC?"

"Script Kiddies" is industry slang for kids who write viruses and then
attempt to deploy them. Not all of them are malicious, but nevertheless
they are PUPs (potentially unwated programs).

"This immediate discussion mentioned proprietary terminals.
If proprietary terminals (allegedly) worked better than
Windows in this situation, can't we achieve the same effect
by having a Windows computer with no access to the internet
and no updates done - at least no automatic updates - to
emulate the situation that proprietary terminals lived in?"

Unfortunately, thats not possible. There will always be a need to control
updates to windows. In the OT (Operational Technology) world, such as
critical infrastructure, these types of PCs run on seperate networks which
are segregated from the business network with firewalls and tightly
controlled access lists.

A very commonly used model for this is the Purdue Model.

Also, everyday business requires an OT HMI PC to access the business
network. We just make sure it is done thru a DMZ. An example is for
electricity usage. The meters report to a PC on a private network. That PC
then has to send usage every day to the main business in order to bill for
usage.

Joe

On Fri, Jul 19, 2024 at 6:54 PM Paul Edwards <
0676ab6435a5-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 19 Jul 2024 18:39:02 -0500, Joe Monk  wrote:
>
> >More to the point, the issue is not Windows, but the abuse of Windows.
> >Example: requiring administrator rights to do ordinary, everyday tasks.
>
> Can you elaborate on this? Who made the decision to require
> admin rights?
>
> >This led to "script kiddies"
>
> Can you elaborate on this too - how did external kids get
> involved in administering your PC?
>
> > which caused us to be defensive on PCs, e.g. Anti-Malware.
>
> This immediate discussion mentioned proprietary terminals.
> If proprietary terminals (allegedly) worked better than
> Windows in this situation, can't we achieve the same effect
> by having a Windows computer with no access to the internet
> and no updates done - at least no automatic updates - to
> emulate the situation that proprietary terminals lived in?
>
> BFN. Paul.
>
> --
> 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: World’s largest computer outage!

[Joe Monk]

More to the point, the issue is not Windows, but the abuse of Windows.
Example: requiring administrator rights to do ordinary, everyday tasks.

This led to "script kiddies" which caused us to be defensive on PCs, e.g.
Anti-Malware.

Joe

On Fri, Jul 19, 2024 at 6:31 PM Steve Beaver <
050e0c375a14-dmarc-requ...@listserv.ua.edu> wrote:

> We never had these problems until Windows showed up
>
>
> Sent from my iPhone
>
> No one said I could type with one thumb
>
> > On Jul 19, 2024, at 18:22, Paul Edwards <
> 0676ab6435a5-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > On Sat, 20 Jul 2024 06:46:40 +1000, Wayne Bickerdike 
> wrote:
> >
> >> Some kind of false economy to make the PC the entire tool of choice for
> >> certain routine tasks.
> >>
> >> In the 1980s we had proprietary banking terminals, private/leased line
> >> point to point communications and passbooks.
> >
> > This is a topic of interest to me. I still program in C90 too.
> > Still restrict myself to S/370 instructions too (quibbling aside).
> >
> > However - for what reason would a proprietary banking terminal
> > be more reliable than a PC? Isn't it more the automatic update
> > feature of the PC that is the issue? That won't protect against
> > a date-related bug in some component though.
> >
> > So perhaps 2 different PC solutions (e.g. the Amiga) - if we're
> > talking 1980s.
> >
> >> No way our branch network would be unable to perform front counter
> >> transactions. We had store and forward whereby local transactions would
> be
> >> kept until the network was back up and running.
> >>
> >> In those days we had 3 ATMs, preferring to let other banks provide that
> >> service and we would absorb the fees.
> >>
> >> I drew out $620 in cash from an ATM yesterday, just a few hours before
> the
> >> crash. Too many people are embracing the cashless world. Time to wake up
> >> and apply some common sense.
> >
> > Are you suggesting using physical cash because software and
> > hardware engineers are unable to create a reliable alternative?
> >
> > The cost of handling physical cash is likely hidden in taxes or
> > whatever. If it was properly costed, maybe IBM mainframes
> > would be part of the solution, and Amigas too?
> >
> > Note that I created PDOS because I didn't want to be dependent on
> > millions of lines of code that I didn't understand and/or didn't have
> > access to. Simplicity. For simple tasks. My wife didn't have access to
> > her bank account for about 6 months because she either wasn't
> > receiving SMSes at all (from this one bank), or they would arrive too
> late.
> >
> > No-one was able to do anything other than say "try again later".
> >
> > 6 digits could have been sent with a Commodore 64 and a 300 bps
> > modem to any spot on earth within 0.2 seconds in the 1980s.
> >
> > That was in 2023, but even in 2024 SMSes still get lost - and other
> > situations too - I think Discord lost a message of mine in 2024.
> > I don't remember a zmodem file transfer ever losing a file of mine.
> >
> > BFN. Paul.
> >
> > --
> > 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: iewl/iebcopy device options

[Joe Monk]

It most certainly does.

https://www.ibm.com/docs/en/zos/2.5.0?topic=ie-example-12-reblock-load-library-distribute-it-different-device-types#u1056

"In this example, a load library is distributed (by copying it) to devices
whose maximum block size differs from that on which the original load
library resides. The library is first reblocked to a maximum block size
that is compatible with each of the devices to which the library will be
copied. Then, the library is copied to those devices."

Joe


On Sun, Jun 16, 2024 at 8:19 PM Seymour J Metz  wrote:

> If you have to unload to 3330, then use BLKSIZE=13030 for SYSLMOD; IEBCOPY
> doesn't support COPYMOD reblocking for load/unload.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Paul Edwards <0676ab6435a5-dmarc-requ...@listserv.ua.edu>
> Sent: Sunday, June 16, 2024 8:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: iewl/iebcopy device options
>
> On Sun, 16 Jun 2024 23:48:56 +, Seymour J Metz  wrote:
>
> > What's wrong with using 3330 or 3350?
>
> I didn't say there was something wrong with them - that's
> basically my question.
>
> > Both have track sizes less than 32KiB.
>
> I wasn't aware that that was even an issue.
>
> But yes - the answer may well be to select 3330.
>
> Maybe I can ask my question a different way to try to get a
> handle on the problem.
>
> Is there an advantage of using 3330 over 3390 (to put a load
> module on with the intention of doing an IEBCOPY unload)?
>
> e.g. will 3330 work on an unmodified MVS 3.8J while 3390 will not?
>
> And the reverse - is there an advantage of using 3390 over 3330?
>
> Note that in 99% of cases, I will be loading to a 3390, not 3330
> or 3350 - so do I lose something by choosing 3330? Like gross
> wastage of space on a 3390 during the load process.
>
> Up till now I have always used 3390, but now I am looking closer
> at that choice.
>
> Thanks. Paul.
>
> --
> 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: iewl/iebcopy device options

[Joe Monk]

"Note that in 99% of cases, I will be loading to a 3390, not 3330
or 3350 - so do I lose something by choosing 3330? Like gross
wastage of space on a 3390 during the load process."

So you would be doing an IEBCOPY with a reblock to the new DASD track size.

Joe

On Sun, Jun 16, 2024 at 7:11 PM Paul Edwards <
0676ab6435a5-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, 16 Jun 2024 23:48:56 +, Seymour J Metz  wrote:
>
> > What's wrong with using 3330 or 3350?
>
> I didn't say there was something wrong with them - that's
> basically my question.
>
> > Both have track sizes less than 32KiB.
>
> I wasn't aware that that was even an issue.
>
> But yes - the answer may well be to select 3330.
>
> Maybe I can ask my question a different way to try to get a
> handle on the problem.
>
> Is there an advantage of using 3330 over 3390 (to put a load
> module on with the intention of doing an IEBCOPY unload)?
>
> e.g. will 3330 work on an unmodified MVS 3.8J while 3390 will not?
>
> And the reverse - is there an advantage of using 3390 over 3330?
>
> Note that in 99% of cases, I will be loading to a 3390, not 3330
> or 3350 - so do I lose something by choosing 3330? Like gross
> wastage of space on a 3390 during the load process.
>
> Up till now I have always used 3390, but now I am looking closer
> at that choice.
>
> Thanks. Paul.
>
> --
> 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: STIMER

[Joe Monk]

TTIMER CANCEL

Joe

On Mon, Apr 8, 2024 at 4:43 PM Tony Thigpen  wrote:

> How do you cancel an outstanding STIMER?
>
> Tony Thigpen
>
> --
> 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: Slow FTP's

[Joe Monk]

Is there a firewall or switch in the path?

Joe

On Thu, Mar 28, 2024 at 8:03 AM Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> Joe,
>
> I had not, just did, worse yet
>
> EZA1485I 12902400 bytes transferred - 10 second interval rate 1281.27
> KB/sec - Overall transfer rate 1281.27 KB/sec
> EZA1485I 21381120 bytes transferred - 10 second interval rate 838.65
> KB/sec - Overall transfer rate 1059.52 KB/sec
> EZA1485I 29491200 bytes transferred - 10 second interval rate 791.23
> KB/sec - Overall transfer rate 969.15 KB/sec
>
> Dave Jousma
> Vice President | Director, Technology Engineering
>
>
>
>
>
> From: IBM Mainframe Discussion List  on behalf
> of Joe Monk <05971158733e-dmarc-requ...@listserv.ua.edu>
> Date: Thursday, March 28, 2024 at 8:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Slow FTP's
> Have you tried MODE S (streaming) and TYPE E? Joe On Thu, Mar 28, 2024 at
> 7: 31 AM Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua.
> edu> wrote: > All, > > Grasping at straws here, IBM support center is
> baffled too. >
>
>
> Have you tried MODE S (streaming) and TYPE E?
>
>
>
> Joe
>
>
>
> On Thu, Mar 28, 2024 at 7:31 AM Jousma, David <
>
> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
>
>
>
> > All,
>
> >
>
> > Grasping at straws here, IBM support center is baffled too.
>
> >
>
> > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS
>
> > dump, and FTP it everywhere it needs to be.  Its roughly a 50Gb file
>
> > transfer.  There is some environmental issue causing slow file transfers
> to
>
> > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other
>
> > systems on the same CEC.With IBM support help, we’ve narrowed down
> the
>
> > problem to the specification of MODE B and EBCDIC on the transfer since
> it
>
> > is a DSS dump.   Remove those, and the transfer is fast on the slow
>
> > systems, and still fast on the fast systems.  Obviously that isn’t a
>
> > solution though.
>
> >
>
> > So, we are a GDPS shop.   The oddity is that all the “fast” transfers are
>
> > to the K systems(control systems), and all the “slow” transfers are to
> the
>
> > traditional application systems.   TEST, DEV, PROD makes no difference,
> nor
>
> > does LPAR busy or not busy.
>
> >
>
> > It seems there is something configured differently on the “slow” systems
>
> > that is affecting mode b, ebcdic file transfers, but for the life of me,
> I
>
> > cannot put my finger on what, nor can the support center, except that the
>
> > issue is at the remote end, in that the OS cannot offload the data fast
>
> > enough, so TCPIP/FTP is slowing the transfer pace.
>
> >
>
> > A virtual adult beverage of choice to the one that can point in a
>
> > direction to look….
>
> >
>
> >
>
> > Dave Jousma
>
> > Vice President | Director, Technology Engineering
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > This e-mail transmission contains information that is confidential and
> may
>
> > be privileged.   It is intended only for the addressee(s) named above. If
>
> > you receive this e-mail in error, please do not read, copy or disseminate
>
> > it in any manner. If you are not the intended recipient, any disclosure,
>
> > copying, distribution or use of the contents of this information is
>
> > prohibited. Please reply to the message immediately by informing the
> sender
>
> > that the message was misdirected. After replying, please erase it from
> your
>
> > computer system. Your assistance in correcting this error is appreciated.
>
> >
>
> > --
>
> > 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
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or disseminate
> it in any manner. If you are not the intended recipient, any disclosure,

Re: Slow FTP's

[Joe Monk]

Have you tried MODE S (streaming) and TYPE E?

Joe

On Thu, Mar 28, 2024 at 7:31 AM Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> All,
>
> Grasping at straws here, IBM support center is baffled too.
>
> To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS
> dump, and FTP it everywhere it needs to be.  Its roughly a 50Gb file
> transfer.  There is some environmental issue causing slow file transfers to
> some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other
> systems on the same CEC.With IBM support help, we’ve narrowed down the
> problem to the specification of MODE B and EBCDIC on the transfer since it
> is a DSS dump.   Remove those, and the transfer is fast on the slow
> systems, and still fast on the fast systems.  Obviously that isn’t a
> solution though.
>
> So, we are a GDPS shop.   The oddity is that all the “fast” transfers are
> to the K systems(control systems), and all the “slow” transfers are to the
> traditional application systems.   TEST, DEV, PROD makes no difference, nor
> does LPAR busy or not busy.
>
> It seems there is something configured differently on the “slow” systems
> that is affecting mode b, ebcdic file transfers, but for the life of me, I
> cannot put my finger on what, nor can the support center, except that the
> issue is at the remote end, in that the OS cannot offload the data fast
> enough, so TCPIP/FTP is slowing the transfer pace.
>
> A virtual adult beverage of choice to the one that can point in a
> direction to look….
>
>
> Dave Jousma
> Vice President | Director, Technology Engineering
>
>
>
>
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or disseminate
> it in any manner. If you are not the intended recipient, any disclosure,
> copying, distribution or use of the contents of this information is
> prohibited. Please reply to the message immediately by informing the sender
> that the message was misdirected. After replying, please erase it from your
> computer system. Your assistance in correcting this error is appreciated.
>
> --
> 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: Principles of Op

[Joe Monk]

linux.mainframe.blog

Joe

On Mon, Feb 19, 2024 at 2:46 PM Steve Thompson  wrote:

> Any one know where IBM is hiding this now?
>
> I've been searching for this to find the latest copy, and I'm
> getting nowhere.
>
> I used to be able to put in IBM TECH LIBRARY and it would be in
> with the z/OS manuals. Can't seem to find it now.
>
> Steve Thompson
>
> --
> 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: How read Cyl 0 from within a program?

[Joe Monk]

Take a look at the CBT, file 846.

I believe the TRK0SAVE program takes the IPL records from a DASD and writes
them out to a dataset.

https://www.cbttape.org/ftp/cbt/CBT846.zip

Joe

On Tue, Feb 13, 2024 at 12:20 PM Charles Mills  wrote:

> I am interested in writing a program to read the IPL records from a DASD
> volume. (Read only, not update). I am comfortable with XDAP but how do I
> OPEN a "dataset" that would include cylinder 0?
>
> APF, OPERATIONS and so forth are not out of the question.
>
> Thanks,
> Charles
>
> --
> 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

Difference between STSI instruction and SYSEVENT QVS?

[Joe Monk]

What (if any) is the difference between the STSI instruction and the
SYSEVENT QVS service, other than maybe the C interface?

Thanks,

Joe

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

Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Joe Monk]

How would that be practical? How would you, for instance, do a batch update
to an encrypted dataset from a CICS vsam file?

Joe

On Mon, Jan 15, 2024 at 2:42 PM Walt Farrell  wrote:

> On Mon, 15 Jan 2024 16:15:38 +, Eric D Rossman 
> wrote:
>
> >Answering a number of comments in order, in one message.
> >
> >First: I don't think being able to encrypt load libraries is worth it.
> Encrypted executables, in general, are not going to increase security.
> >
> >Jousma, David:
> >
> >> Additionally, I think IBM dropped the ball a bit in that
> >> nothing stops a permitted user to copy that data to an
> >> un-encrypted dataset.
> >
> >Another topic we discussed. Here's the rub: How would you
> >implement that? What would prevent one application from opening
> >a data set and reading, then closing it and opening a new data
> >set to write out. How would IBM detect that? I get that we could
> >have prevented it for IDCAMS REPRO or similar programs but it
> >would impossible to do it reliably for all possible programs.
> >
>
> RACF did something you could consider as a model, with EXECUTE access to
> programs. Once a user has loaded a program that they only have EXECUTE
> authority for (not READ), they cannot load another program that is not
> Program Controlled. (There's a bit more to it, but that's sufficient for
> this discussion, I think.)
>
> For encryption, the analogous method might be: Once a jobstep has Opened
> an encrypted data set to read it, they cannot write to, nor Open, an
> unencrypted output data set. You just mark the jobstep, and have a bit in
> the DEB indicating encryption, and for a marked jobstep you don't allow a
> write to a DEB that doesn't have the bit set.
>
> I can't say whether that would solve any real problems, but if there's a
> concern about someone reading an encrypted file and writing it unencrypted,
> that could solve part of it. The next layer, though, might be wanting to
> protect against them sending it over the network, and being sure how it's
> treated at the other end if they do.
>
> --
> Walt (former lead RACF designer/architect for that function)
>
> --
> 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: Opinion

[Joe Monk]

Second this. I have a DELL 42" monitor which I used with multiple computers.

Joe

On Mon, Jan 15, 2024 at 12:26 PM Henri Kuiper 
wrote:

> All I can say is, if you have multiple devices, go for a monitor that also
> acts as a KVM-switch... I've a DELL Dell C3422WE at "only" 34" but the
> ability to switch between the laptop and the desktop is a-ma-zing :)
>
> you got me pondering on a 49" now thanks :)
>
> [image: __tpx__]
> [image: photo] 
>
> Henri Kuiper
> Chief Technology Officer, CTO
>
> [image: linkedin] 
>
> * P * +31 (0) 6392 19574 <+31+(0)+6392+19574>   * W * mainframesociety.com
>
> * E * he...@mainframesociety.com *M *Book a Google Meet
> <
> https://calendar.google.com/calendar/u/0/appointments/schedules/AcZssZ3PJqcEmZGUpw6THFN12mJnnHRF003i3ALwXg4iXYwXzAAuVtCBVrJVR-2acuNbL77aSHfceHX_
> >
>
>
>
> On Mon, 15 Jan 2024 at 19:10, Lionel B. Dyck  wrote:
>
> > I use two 34" curved monitors side by side 😊
> >
> >
> > Lionel B. Dyck <><
> > Github: https://github.com/lbdyck
> >
> > “Worry more about your character than your reputation. Character is what
> > you are, reputation merely what others think you are.”   - - - John
> Wooden
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Bill Hitefield
> > Sent: Monday, January 15, 2024 11:38 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Opinion
> >
> > Steve,
> >
> > I have not used that specific monitor, but I do use a curved monitor.
> Love
> > it! For me, much better than a flat monitor. I was hooked after I tried
> the
> > first one (a Samsung).
> >
> > Bill Hitefield
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Steve Beaver
> > > Sent: Monday, January 15, 2024 12:33 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Opinion
> > >
> > > Does anyone have an opinion on
> > >
> > >
> > >
> > > LG - 49" IPS LED Curved UltraWide Dual QHD 144Hz FreeSync and G-SYNC
> > > Compatible Monitor with HDR (HDMI, DisplayPort, USB) - Black
> > >
> > >
> > >
> > >
> > >
> > > Steve Beaver
> > >
> > >
> > >
> > >
> > > --
> > > 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: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Joe Monk]

   1.

   Restrictions for encrypted data sets
   -

  System data sets (such as Catalogs, SMS control data sets, SHCDS, HSM
  data sets) must not be encrypted, unless otherwise specified in
  product documentation.
  -

  Data sets used during IPL must not be encrypted.


Page 5

https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5izsp100/$file/izsp100_v2r5.pdf

Joe

On Sat, Jan 13, 2024 at 11:06 AM Radoslaw Skorupka <
0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:

> I can imagine technical reason to not encrypt such libraries.
> However encryption is a kind of data protection. Data. Not programs.
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> W dniu 13.01.2024 o 17:28, Steve Estle pisze:
> > Everyone,
> >
> > Our team is knee deep into pervasive encryption rollout on ZOS 2.5 and
> despite the fact such functionality has been out for years by IBM to do
> this, it is quite surprising how many software vendors when you contact
> them they have no clue what you're talking about - that is a complete aside
> - I'm not going to name vendors here but if you want some examples you can
> contact me offline.
> >
> > My true reason for composing this is that we've discovered the inability
> to encrypt load libraries - even in PDSE format.  I've yet to get a
> straight answer from IBM on why this is?...   Is this a "giant" technical
> hurdle for IBM?  Or is it just cause there hasn't been anyone who raised
> the need yet?  If the latter does this capability interest others here if I
> were to raise as an IBM idea - would you vote for it?
> >
> > I know this seems innocuous, but we'd like to encrypt as much as
> possible in our environment and due to Top Secret deficiencies we have to
> encrypt at high level qualifier level (HLQ) (all or nothing under each HLQ
> unfortunately).  Given we have load module libraries under many differ
> HLQ's this is posing difficulties in moving forward with our rollout when
> an HLQ does have one or more load module libraries as part of that HLQ.
> You can only imagine the pain of renaming a load library given all the JCL,
> etc that is referencing that library name.
> >
> > Also, while encrypting load module libraries might seem a little far
> fetched, there are of course many malicious viruses that have been launched
> by injecting code into a suspecting piece of code.
> >
> > So two questions:
> >
> > 1. Why has IBM not already provided such functionality - can anyone
> speak to the technical hurdles to provide?
> > 2. If I were to submit an IBM idea, can I count on this community for
> some backing here to help in upvoting such an idea submission?
> >
> > Thanks for your indulgence,
> >
> > Steve Estle
> > sest...@gmail.com
> > Peraton systems programmer
> >
> > --
> > 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: Programatically setting JCL symbolsragg

[Joe Monk]

On Wed, Oct 18, 2023 at 16:28 Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 18 Oct 2023 16:18: 05 -0500, Charles Hardee wrote:
> >
> >Thanks in advance for anyone that can shed light on the subject.
> >
> >Is there a umechanism for setting a JCL type variable from within a
> program?c as
> >
> I hope you can't.
>
> JCL symbols are elaborated by the Converter, before a program executes.
>
> 
>
> --
> 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: Simple request from chatGPT to write assembler program.

[Joe Monk]

"LexisNexis is over 200 years old..."

Bull. LexisNexis was started by a lawyer in 1956...

Joe

On Wed, Sep 6, 2023 at 7:57 AM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> Shocking, LexisNexis is over 200 years old and is designed specifically
> for legal purposes. ChatGPT is less than a year old and isn’t designed
> (yet) for the legal profession.
>
> Good choice picking the LexisNexis one.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Wednesday, September 6, 2023, 8:48 AM, Dean Kent 
> wrote:
>
> Which brings up another 'interesting' anecdote.   I used chatGPT to
> 'write' a set of bylaws for a new non-profit for a youth sports club.
> I asked it over a dozen times with different wording, and it came back
> with a wide variety of results - some that were long and included many
> sections, and others that were short and included only what might be
> considered 'necessary' sections.I have a friend who is an attorney,
> and he sent me the template that LexisNexis provides.   It had a lot
> more content, some which the IRS now indicates is 'preferred' or even
> required.So I ended up using the template since I could just remove
> or ignore sections that weren't pertinent.   The template also had a
> variety of options (variables, if you will) for wording depending on,
> for example, if the corporation has a CEO or President and whether board
> officers can also be corporate executives, etc.
>
> That caused me to make the decision that I would not consider using
> chatGPT for creating legal documents.   Again, YMMV.
>
> On 9/5/2023 12:27 PM, Steve Thompson wrote:
> > And so we can now understand that when a paralegal or newly minted
> > attorney uses it to find case law for points and authorities, it will
> > will make them up to match what was being searched for when it
> > prepares a motion it was asked for using the results of the search.
> >
> > And some attorneys got a judge quite angry with them when they didn't
> > tell the court this, but the opposing council pointed out they could
> > not find any such case listed in the pleadings/motion. Then the
> > judge's people also could not find same This is the kind of thing
> > that concerns me about AI today. Once it has been taught enough to
> > learn on its own
> >
> > Steve Thompson
> >
> > On 9/5/2023 12:46 PM, Dean Kent wrote:
> >> I spent a bit of time playing with chatGPT to see what it could do.
> >> So did my two sons - one an MS in biotech, the other a PhD in
> >> theoretical physics.We all came to the same conclusion - chatGPT
> >> is a very, very good Google search that can filter many different
> >> possible 'answers' and come to one that is 'most likely' based on
> >> various factors.  It has little to no creativity or understanding of
> >> what it is asked to do.   Not surprising, but different than what the
> >> popular press seems to say about it.
> >>
> >> One of my questions was to write a simple sort routine in HLASM. It
> >> came back with a template containing the entry/exit code, and then a
> >> comment *insert sort routine here*.After doing that with many
> >> different simple tasks, I came to the conclusion that the problem
> >> chatGPT has with assembler (but not with C, Python, Java, etc.) is
> >> that there are so few searchable examples of code in assembler.So
> >> the quality of the results, for any question, depends upon what
> >> exists out on the Internet.   Again, not surprising.
> >>
> >> As another example, I have an interest in what is called 'historical
> >> analysis'.   There are a number of books on the subject, so I asked
> >> chatGPT to compare/contrast two of the books.   Then two other books,
> >> etc.In literally every case it came back with the same
> >> introductory text and conclusion - but inserted a couple of
> >> paragraphs that was similar to a book review for each book and
> >> compared the 'differences'.   Not very impressed.
> >>
> >> My PhD son uses it to find obscure hypotheses and formulas that would
> >> otherwise require a great many hours (or days) of searching.   My MS
> >> son uses it in a similar fashion to ferret out alternative options
> >> for the various cell growing and protein extraction for his job.   A
> >> very useful tool, but not yet SkyNet...
> >>
> >> YMMV.
> >>
> >> On 9/5/2023 9:36 AM, Bill Johnson wrote:
> >>> We are all retired. The other 2 went before me. I went in July 2022.
> >>> You’re an idiot regardless. What are you afraid of? That a computer
> >>> can do what you do? That your “skills” aren’t all that impressive
> >>> and can be automated away?
> >>>
> >>>
> >>> Sent from Yahoo Mail for iPhone
> >>>
> >>>
> >>> On Tuesday, September 5, 2023, 12:25 PM, David Spiegel
> >>> <0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:
> >>>
> >>> Hi Bill,
> >>> I have a better idea.
> >>> Why don't you and the 2 buddies who helped you modify the IEFUSI fix
> >>> it?
> >>> Probably because you don't have the wherewitha

Re: Simple request from chatGPT to write assembler program.

[Joe Monk]

It will abend for sure.

Joe



On Tue, Sep 5, 2023 at 5:52 PM Bernd Oppolzer 
wrote:

> It will not work, because almost every single instruction has an error
> or two.
> Every programmer with a little bit ASSMBLER experience can see this;
> this ChatGPT program has no grasp of instruction formats, DCBs or the
> proper
> use of I/O macros. I will not go into the details here ... the ASSEMBLER
> people know
> what I'm talking about, and the others are not interested.
>
> Kind regards
>
> Bernd
>
>
> Am 05.09.2023 um 18:00 schrieb Bill Johnson:
> > Why do you doubt it? Is it because you hope it doesn’t? Certainly, one
> of you assembler geniuses could test it.
> >
> > Like Mullins said, and others mentioned, most companies that run z/OS
> don’t need assembler programmers. That numbers in the thousands if not ten
> thousand. Whereas ISV’s who are the likely users of Assembler programming,
> number in the hundreds, maybe. So install on Systems Programmers.
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Tuesday, September 5, 2023, 11:43 AM, Steve Thompson 
> wrote:
> >
> > I doubt it will assemble. And even if it does, the results are
> > unpredictable, other than it will probably ABEND for one reason
> > or another.
> >
> > There are no DCB, OPEN, CLOSE macros while GET and PUT are being
> > used.
> >
> > Me thinks this AI system is confusing a few different assembly
> > languages together. I wonder how close they came for DOS I/O.
> > Steve Thompson
> >
> >
> >
> > On 9/5/2023 11:20 AM, Tom Marchant wrote:
> >> You're right, Tom. That is not a program. Certainly not one that will
> do what it claims to do.
> >>
> >> -- Tom Marchant On Mon, 4 Sep 2023 10:42:51 -0700, Tom Brennan
> >>  wrote:
> >>> I can't be sure I formatted it properly, but after looking over the
> >>> code, I have nothing to say but WTF? 😄
> >>>
> >>>PRINT NOGEN
> >>>TITLE 'Simple Addition Program'
> >>> ** Define storage for input numbers and result
> >>> *
> >>> NUM1DSFFirst input number
> >>> NUM2DSFSecond input number
> >>> RESULT  DSFResult of addition
> >>> ** Main program
> >>> *
> >>> MAINC  0NUM1  Check if NUM1 is zero
> >>>BEZEROBranch to ZERO if true
> >>> ** Read the first number from input
> >>> *
> >>>GETNUM1,NUMIN  Read NUM1 from input
> >>>LA0,NUM1  Load NUM1 into register
> >>> ** Read the second number from input
> >>> *
> >>>GETNUM2,NUMIN  Read NUM2 from input
> >>>A  NUM1,NUM2  Add NUM1 and NUM2
> >>>STNUM1,RESULTStore the result in RESULT
> >>> ** Print the result
> >>> *
> >>>PUTRESULT,NUMOUT  Print the result
> >>> ** Terminate the program
> >>> *
> >>>SR15,15  Set return code to 0
> >>>BR14  Return to caller
> >>> ** Define input and output areas
> >>> *
> >>> NUMINDCF'0'  Input buffer for numbers
> >>> NUMOUT  DCF'0'  Output buffer for result
> >>> ZERODCF'0'  Constant zero
> >>>END  MAINEnd of program
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email tolists...@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: Simple request from chatGPT to write assembler program.

[Joe Monk]

It doesn't even establish addressability.

Joe

On Tue, Sep 5, 2023 at 5:52 PM Bernd Oppolzer 
wrote:

> It will not work, because almost every single instruction has an error
> or two.
> Every programmer with a little bit ASSMBLER experience can see this;
> this ChatGPT program has no grasp of instruction formats, DCBs or the
> proper
> use of I/O macros. I will not go into the details here ... the ASSEMBLER
> people know
> what I'm talking about, and the others are not interested.
>
> Kind regards
>
> Bernd
>
>
> Am 05.09.2023 um 18:00 schrieb Bill Johnson:
> > Why do you doubt it? Is it because you hope it doesn’t? Certainly, one
> of you assembler geniuses could test it.
> >
> > Like Mullins said, and others mentioned, most companies that run z/OS
> don’t need assembler programmers. That numbers in the thousands if not ten
> thousand. Whereas ISV’s who are the likely users of Assembler programming,
> number in the hundreds, maybe. So install on Systems Programmers.
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Tuesday, September 5, 2023, 11:43 AM, Steve Thompson 
> wrote:
> >
> > I doubt it will assemble. And even if it does, the results are
> > unpredictable, other than it will probably ABEND for one reason
> > or another.
> >
> > There are no DCB, OPEN, CLOSE macros while GET and PUT are being
> > used.
> >
> > Me thinks this AI system is confusing a few different assembly
> > languages together. I wonder how close they came for DOS I/O.
> > Steve Thompson
> >
> >
> >
> > On 9/5/2023 11:20 AM, Tom Marchant wrote:
> >> You're right, Tom. That is not a program. Certainly not one that will
> do what it claims to do.
> >>
> >> -- Tom Marchant On Mon, 4 Sep 2023 10:42:51 -0700, Tom Brennan
> >>  wrote:
> >>> I can't be sure I formatted it properly, but after looking over the
> >>> code, I have nothing to say but WTF? 😄
> >>>
> >>>PRINT NOGEN
> >>>TITLE 'Simple Addition Program'
> >>> ** Define storage for input numbers and result
> >>> *
> >>> NUM1DSFFirst input number
> >>> NUM2DSFSecond input number
> >>> RESULT  DSFResult of addition
> >>> ** Main program
> >>> *
> >>> MAINC  0NUM1  Check if NUM1 is zero
> >>>BEZEROBranch to ZERO if true
> >>> ** Read the first number from input
> >>> *
> >>>GETNUM1,NUMIN  Read NUM1 from input
> >>>LA0,NUM1  Load NUM1 into register
> >>> ** Read the second number from input
> >>> *
> >>>GETNUM2,NUMIN  Read NUM2 from input
> >>>A  NUM1,NUM2  Add NUM1 and NUM2
> >>>STNUM1,RESULTStore the result in RESULT
> >>> ** Print the result
> >>> *
> >>>PUTRESULT,NUMOUT  Print the result
> >>> ** Terminate the program
> >>> *
> >>>SR15,15  Set return code to 0
> >>>BR14  Return to caller
> >>> ** Define input and output areas
> >>> *
> >>> NUMINDCF'0'  Input buffer for numbers
> >>> NUMOUT  DCF'0'  Output buffer for result
> >>> ZERODCF'0'  Constant zero
> >>>END  MAINEnd of program
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email tolists...@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: Is the IBM Assembler List still alive

[Joe Monk]

Assembler is only relevant to the Machine.

Joe

On Mon, Sep 4, 2023 at 12:23 AM Matt Hogstrom  wrote:

> Assembler is only relevant to the Runtime
>
> Matt Hogstrom
> PGP key 0F143BC1
>
> > On Sep 3, 2023, at 13:26, Paul Gilmartin <
> 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > How important are Assembler skills for a  Linux for zSeries applications
> programmer?
> > A systems programmer?  Why?  Hardware interfaces?  Other z control area
> > definitions?
> >
> > Which assembler?  HLASM?  GNU Assembler?  Other?
>
> --
> 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: z13s going EOS anytime soon?

[Joe Monk]

https://www.ibm.com/support/pages/system/files/inline-files/IBM%20Mainframe%20Life%20Cycle%20History%20V2.13%20-%20July%2011%202023.pdf
- slide 4

z13s is EOS on 12/31/2024.

Joe

On Mon, Aug 28, 2023 at 1:58 PM Claude Richbourg <
claude.richbo...@myfloridacfo.com> wrote:

> Good afternoon,
>
> We are currently running on a z13s -2965 and I just started the planning
> process of going to a newer processor sometime soon.
>
> Has anyone heard when the official IBM EOS will be for the z13s?
> I have seen different dates 06-30-2026 and now 12-31-2024, so I am not
> sure what the real EOS is.
>
> If anyone knows what IBMs official stance is on the 2965, I would surely
> like to know.
>
> Thanks up front.
>
>
> Best Regards,
> Claude
>
> --
> 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: OSA-ICC question

[Joe Monk]

I think he was asking about the hosting company.

They will always have access via the HMC. In addition, since their network
will be used to access the OSA-ICC port, they will have access via that
method.

Joe

On Wed, Jul 12, 2023 at 8:01 AM Tom Longfellow <
03e29b607131-dmarc-requ...@listserv.ua.edu> wrote:

> I am confused about which 'access' is at question.
>
> There is access to the card and access to the lpars using the card.
> Basically the wires in and out of the physical OSA-ICC card.
>
> ANYONE that has connectivity to the Ethernet port on the OSA is
> 'accessing' the OSA.
> The 'OSA Specific Utilities' under HMC control then controls what LPARS
> the people who 'access' the OSA can see within your mainframe..
> The LPARS must also be told about the OSA-ICC.
>
> None of this will give them 'Access' to your operating systems or
> applications.  In other words, they will still have to authenticate and
> login just like any users of the systems.
>
> It boils down to the trust you have in your outsourcer.They are the
> fox in charge of this hen house.IF they are sharing the physical OSA
> across all customers, then the OSA-ICC configuration becomes your
> gatekeeper/firewall to keep everyone isolated.
>
> Makes me wonder what the concerns are and what 'accesses'  are being
> question.  Also, what access?  physically, to the applications and data?
> etc.
>
> --
> 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: OSA-ICC question

[Joe Monk]

Basically, as long you have access to the IP subnet, you have connectivity
to the defined OSA-ICC.

Joe

On Tue, Jul 11, 2023 at 10:53 PM kekronbekron <
02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:

> For our benefit here, could you please share what the conclusion is?
>
>
> - KB
>
> --- Original Message ---
> On Wednesday, July 12th, 2023 at 9:17 AM, Laurence Chiu 
> wrote:
>
>
> > Thanks. I thought as much as Googled for this but this link didn't pop
> up.
> > That is pretty conclusive.
> >
> > On Wed, Jul 12, 2023 at 12:11 PM Joe Monk joemon...@gmail.com wrote:
> >
> > > Page 129
> > >
> > > https://www.redbooks.ibm.com/redbooks/pdfs/sg245444.pdf
> > >
> > > Joe
> > >
> > > On Tue, Jul 11, 2023 at 5:12 PM Laurence Chiu lch...@gmail.com wrote:
> > >
> > > > We are having a LPAR being stood up on an outsourcing company's
> host. It
> > > > will be for our use but they will manage it via the HMC's and
> possibly
> > > > the
> > > > OSA-ICC port. All regular access to the LPAR will be via 3270 and
> using
> > > > our accounts. But a question was asked, what about OSA-ICC access. My
> > > > understanding is if the OSA Express cards have been defined in IOCD
> and
> > > > assigned to the LPAR, and a port(s) configured as OSA-ICC then the
> > > > outsourcer can access it so long as they have IP connectivity to
> that IP
> > > > address. And Z/OS Communications Manager does not need to be started.
> > > >
> > > > Is that correct? This is not my area of expertise but one of my
> > > > colleagues
> > > > said the OSA Express cards are assigned to the hardware and not to
> the
> > > > LPAR
> > > > which of course makes no sense to me at all. After all you can share
> OSA
> > > > Express cards across the LPARs on a CEC.
> > > >
> > > >
> --
> > > > 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: OSA-ICC question

[Joe Monk]

Page 129

https://www.redbooks.ibm.com/redbooks/pdfs/sg245444.pdf

Joe

On Tue, Jul 11, 2023 at 5:12 PM Laurence Chiu  wrote:

> We are having a LPAR being stood up on an outsourcing company's host. It
> will be for our use but they will manage it via the HMC's and possibly the
> OSA-ICC port.  All regular access to the LPAR will be via 3270 and using
> our accounts.  But a question was asked, what about OSA-ICC access. My
> understanding is if the OSA Express cards have been defined in IOCD and
> assigned to the LPAR, and a port(s) configured as OSA-ICC then the
> outsourcer can access it so long as they have IP connectivity to that IP
> address. And Z/OS Communications Manager does not need to be started.
>
> Is that correct? This is not my area of expertise but one of my colleagues
> said the OSA Express cards are assigned to the hardware and not to the LPAR
> which of course makes no sense to me at all. After all you can share OSA
> Express cards across the LPARs on a CEC.
>
> --
> 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: Cobol question

[Joe Monk]

You can always map the TCB and reference field TCBTTIME to get the
accumulated CPU time for the task - I think its offset 316 decimal.

Joe

On Tue, Jul 11, 2023 at 4:22 PM Pommier, Rex 
wrote:

> Hey all,
>
> I just got this tossed at me by an application developer.  Cobol 6.3.  Is
> there some built-in function or something that they can put into a program
> to report out the amount of CPU (TCB) time the program has consumed thus
> far in execution of the program?  We have a program that processes
> accounts, and at the beginning of every account it prints the account
> number and wall clock timestamp.  The developers would like to also report
> out how much CPU the program has consumed at the same time as the wall
> clock.   I don't know of any but if somebody has an idea off the top of
> their head, I'll listen.
>
> TIA,
>
> Rex
>
> --
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged. If the reader of this message is
> not the intended recipient or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any disclosure, distribution, copying, or any action taken or action
> omitted in reliance on it, is strictly prohibited and may be unlawful. If
> you have received this communication in error, please notify us immediately
> by replying to this message and destroy the material in its entirety,
> whether in electronic or hard copy format. 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: PCRE2 source code ....

[Joe Monk]

Ok well you can also get it from the github link I shared with you

On Sun, Jun 11, 2023 at 10:59 AM Dave Jones  wrote:

> Thanks, Joe, but I don't have access to a z/OS system to perform those
> steps.
> Take care.
> DJ
>
> --
> 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: PCRE2 source code ....

[Joe Monk]

Dave,

Those are TSO TRANSMIT files. The hint is in the first record ... *\INMR01

There is a $INSTALL member that is in REXX. It will install all these
files...

 Prompting will occur for hlq and optional volser.





   and it will then issue the TSO RECEIVE command for the


   the following members to create these new data sets:





   Member   Dataset


   ASM  hlq.ASM


   CNTL hlq.CNTL


   COB  hlq.COB


   C14MACLB hlq.C14MACLB


   JCL  hlq.JCL


   LOADLIB  hlq.LOADLIB


   SRCE hlq.SRCE


   TESTLIB  hlq.TESTLIB





   You will then need to copy these datasets/members into


   datasets for production use.





   After these data sets are created several of the members


   of this install data set will be browsed.

Joe

On Sun, Jun 11, 2023 at 10:40 AM Dave Jones  wrote:

> Thanks, Joe.
> I have downloaded the XMIT file from the CBT site to my Winows 11 laptop
> here and used the XmitManager app to open it. I see several members that
> appear to be plain text files (the notes, JCL, etc.) but the SCRE member
> doesn't appear to be just plain text. Maybe an unloaded PDS? How can I
> access that from my Windows PC?
> Many thanks, again.
> DJ
>
> --
> 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: PCRE2 source code ....

[Joe Monk]

Also, https://github.com/PCRE2Project/pcre2

Joe



On Sun, Jun 11, 2023 at 8:02 AM Dave Jones  wrote:

> Hello, all.
> Is there any place where I could access and download the PCRE2 source code
> from the port by Ze'ev Atlas? That might be useful to folks that don't have
> easy access to a z/OS image...
> Thanks.
> DJ
>
> --
> 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: PCRE2 source code ....

[Joe Monk]

CBTTAPE 939

Joe

On Sun, Jun 11, 2023 at 8:02 AM Dave Jones  wrote:

> Hello, all.
> Is there any place where I could access and download the PCRE2 source code
> from the port by Ze'ev Atlas? That might be useful to folks that don't have
> easy access to a z/OS image...
> Thanks.
> DJ
>
> --
> 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: COBOL question: How to dynamically get the name of the routine that called you

[Joe Monk]

You use the LE service CEETBCK. This is the traceback utility and can be
used to walk the call chain backwards from Enteprise COBOL.

Joe



On Tue, May 2, 2023 at 12:08 PM Schmitt, Michael 
wrote:

> I wrote an assembler subprogram that gets the name of the caller of the
> caller, i.e. if A > B > asm, it returns A. Or any number of levels up that
> you want. It works for static and dynamic calls, for both Language
> Environment compatible and non-LE programs.*
>
> The logic to get the program name is non-trivial. For example, in an LE
> compatible program it depends on if the Program Prolog Area is in FASTLINK
> format or not.
>
> I don't think this is possible to do in straight COBOL, because how would
> you get access to the registers for the save area chain? But maybe there's
> an LE service that could help.
>
>
> Let me know if you're interested in the assembler program.
>
>
> * assuming the program follows standard conventions for the program id
> signature string.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Farley, Peter
> Sent: Tuesday, May 2, 2023 11:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: COBOL question: How to dynamically get the name of the routine
> that called you
>
> This is an Enterprise COBOL V5/6 question.  No earlier compiler versions
> are involved.
>
> Is it possible for a called COBOL program to dynamically determine the
> name of the calling COBOL program (i.e., the PROGRAM-ID value)?  I have
> been reading the LE Vendor Interfaces manual but I have yet to figure out
> now to use any of the documented services or control blocks to get the name
> of the caller.
>
> I need this for determining from where a high-usage subroutine is being
> called unnecessarily in a large main program (many called modules with
> multiple levels of CALL, but no recursion).  The subroutine unfortunately
> is NOT passed the name of the caller in the LINKAGE parameters (that would
> have been too easy . . . ).
>
> Any RTFM pointers or process to follow to get the caller's name would be
> appreciated.  I am willing to set up an assembler stub routine to capture
> the data if it cannot be done directly from the COBOL called subroutine.
>
> Peter
> --
>
>
> 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
>
> --
> 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: Inexplicable 0C4!

[Joe Monk]

"If the operation is completed with condition code 0, the contents of
general register R1 are incremented by the contents of general register R1 +
1, and then the contents of general register R1 + 1 are set to zero. If the
operation is completed with condition code 1, the contents of general
register R1 + 1 are decremented by the number of bytes processed before the
first-operand byte equal to the test byte was encountered, and the contents
of general register R1 are incremented by the same number, so that general
register R1 contains the address of the equal byte. If the operation is
completed with condition code 3, the contents of general register R1 + 1
are decremented by the number of bytes processed, and the contents of
general register R1 are incremented by the same number, so that the
instruction, when reexecuted, resumes at the next byte to be processed."

I think you may want to re-evaulate your BC processing...

Joe

On Thu, Apr 27, 2023 at 8:53 AM Binyamin Dissen 
wrote:

> Which flavor of 0C4?
>
> If PIC-10/11, the address is reported.
>
> On Thu, 27 Apr 2023 19:58:23 +0700 Robin Atwood 
> wrote:
>
> :>I have had two of these during the course of two months, so it's getting
> :>serious!
> :>
> :>The abend happens in my implementation of a C strupr() function when the
> TRE
> :>instruction is executed:
> :>
> :>
> :>
> :> L   R3,=X'7FFF'string maximum length
> :>
> :> XRR0,R0  zero terminator byte
> :>
> :> LA R1,UPRXtranslate table
> :>
> :>TST  TRE   R2,R1  fold string
> :>
> :> BC 1,TSTresume translation
> :>
> :>
> :>
> :>   R0  R1 R2  R3
> :>PSW
> :>
> :> 0009C5EC 1AA748F8 7FFF  078D04008009BD14
> :>
> :>
> :>
> :>The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so
> bog
> :>standard. I know R3
> :>
> :>looks dodgy, but that is because the string to be upper-cased must be
> zero
> :>byte terminated.
> :>
> :>R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all
> :>this, why has the instruction caused an
> :>
> :>abend? The code lives in a server that is running all day, every day. I
> :>wondered if the target data had been
> :>
> :>released by another task, but VSMDATA showed a DQE for the data's page
> and
> :>no FQE for the data itself,
> :>
> :>so the data should still be available (as I understand it). Notice R3
> hasn't
> :>changed, so the abend happened
> :>
> :>on the very first byte.
> :>
> :>
> :>
> :>Any suggestions gratefully received!
> :>
> :>Robin
> :>
> :>
> :>
> :>
> :>
> :>
> :>
> :>
> :>--
> :>For IBM-MAIN subscribe / signoff / archive access instructions,
> :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
> --
> 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: COBOL question

[Joe Monk]

A lot of times, U4038 is not enough region...

Joe

On Mon, Apr 10, 2023 at 6:15 AM Cameron Conacher <
03cfc59146bb-dmarc-requ...@listserv.ua.edu> wrote:

> Good call 😊
>
> I ALLOCATE once.
> And just before GOBACK, I issue the FREE. Just one time.
> I am thinking it might be related to EXPEDITER.
>
> That is my current WAG.
>
>
> Thanks
>
> …….Cameron
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Charles Mills
> Sent: Sunday, April 9, 2023 8:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: COBOL question
>
> I can't see your code of course but my WAG is a programmer logic error.
> (Sorry!) I am going to guess your logic is such that you try to free the
> same area twice or, less likely, corrupt your pointer.
>
> You say you check to see if it is null before freeing. Do you set it to
> NULL after freeing?
>
> Charles
>
> On Sun, 9 Apr 2023 23:01:05 +, Cameron Conacher <
> cameron.conac...@aexp.com> wrote:
>
> >Thanks Bob,
> >No I initialize the Pointer to NULL, and then allocate. Successfully.
> >And then later I check to see it the pointer = NULL. If it is not NULL,
> then I do the FREE.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> American Express made the following annotations
> 
> This e-mail was sent to you by a representative of Amex Bank of Canada,
> P.O. Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca.
> If you no longer wish to receive these e-mails, please notify the sender by
> reply e-mail.
>
> This e-mail is solely for the intended recipient and may contain
> confidential or privileged information. If you are not the intended
> recipient, any disclosure, copying, use, or distribution of the information
> included in this e-mail is prohibited. If you have received this e-mail in
> error, please notify the sender by reply e-mail and immediately and
> permanently delete this e-mail and any attachments. Thank you.
>
> American Express a fait les remarques suivantes
> Ce courriel vous a été envoyé par un représentant de la Banque Amex du
> Canada, C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7,
> www.americanexpress.ca. Si, par la suite, vous ne souhaitez plus recevoir
> ces courriels, veuillez en aviser les expéditeurs par courriel.
>
> Ce courriel est réservé au seul destinataire indiqué et peut renfermer des
> renseignements confidentiels et privilégiés. Si vous n’êtes pas le
> destinataire prévu, toute divulgation, duplication, utilisation ou
> distribution du courriel est interdite. Si vous avez reçu ce courriel par
> erreur, veuillez en aviser l’expéditeur par courriel et détruire
> immédiatement le courriel et toute pièce jointe. Merci.
>
> --
> 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: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Joe Monk]

"I know more about banking than you know it alls."

You dont know what you dont know.

Joe

On Thu, Apr 6, 2023 at 9:16 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> I know more about banking than you know it alls. Already proved Crayford
> wrong regarding the challenger banks. And ING dropped their mainframe as
> their stock price is cut in half the last 20 years. Explain the complex
> reasons or are you making that up too?
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, April 6, 2023, 10:11 PM, Doug  wrote:
>
> For alot more complex reasons than your simplistic view of banking.
> Perhaps some time learning real banking might help. Or some
> macroeconomics to go along with it. I've made plenty over the years on
> the right bank investments. And took some risks with others. But I
> actually understand the business.
> And despite your pronouncement, plenty of retail banks are quite
> profitable.
>
> Doug Fuerst
> d...@bkassociates.net
>
> -- Original Message --
> From: "Bill Johnson" <0047540adefe-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@listserv.ua.edu
> Sent: 06-Apr-23 20:19:39
> Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by
> value]
>
> >I did. Mellon Bank during the transition from retail bank to investment
> bank. Retail banking sucks for profits. That’s why Citi is selling for 6
> times earnings. ING stock would have lost you a ton of money over the last
> 20 years. Why are bank stocks selling at a huge discount to the market?
> >
> >
> >Sent from Yahoo Mail for iPhone
> >
> >
> >On Thursday, April 6, 2023, 8:06 PM, Doug  wrote:
> >
> >Maybe you should have actually worked in retail banking, which clearly,
> >you never have.
> >
> >
> >Doug Fuerst
> >d...@bkassociates.net
> >
> >-- Original Message --
> >From: "Bill Johnson" <0047540adefe-dmarc-requ...@listserv.ua.edu>
> >To: IBM-MAIN@listserv.ua.edu
> >Sent: 06-Apr-23 19:16:58
> >Subject: Re: Stop the ragging on COBOL please [was: RE: ASM call by
> >value]
> >
> >>Like I said, there’s little money in retail banking. And zero money to
> be made in challenger banking. It’s why they are all shrinking or closed.
> Mellon bank saw this 20+ years ago. ING & others are focusing more on
> investment banking. Mostly for the high net worth people but also people in
> our financial arena. It’s why Bank of America agreed to take on Merrill
> Lynch in 2008 during the meltdown. And still can’t make much money because
> of their focus on retail banking. Wells Fargo got fined a bundle for trying
> to rip off consumers because there’s little money in retail banking. Most
> banks are trying to get into investment banking where significant money can
> be made. Quasi Goldman Sachs or Morgan Stanley like.
> >>
> >>You can see how precarious the economy is for retail banking companies
> by how quickly they can become insolvent. Even a bank considered excellent
> because of their clientele like SVB. Then Credit Suisse almost went belly
> up until UBS saved them. Deutsche Bank isn’t exactly a bastion of
> profitability either. Citibank almost went belly up in 2008. One of the
> largest banks in the world. Anyone who claims banking, especially retail
> banking is a profit generating machine is not paying attention.
> >>
> >>
> >>Sent from Yahoo Mail for iPhone
> >>
> >>
> >>On Thursday, April 6, 2023, 6:07 PM, René Jansen <
> rene.vincent.jan...@gmail.com> wrote:
> >>
> >>They will be disappointed if they hear that, there are a fusion between
> Rijkspostspaarbank, NMB (Nederlansche Middenstandsbank, Postcheque en
> Girodienst, and Nationale Nederlanden. They are a very large bank in the
> Netherlands. And yes they are off the mainframe, running a lot of mainframe
> stuff on Micro Focus.
> >>
> >>best regards,
> >>
> >>René.
> >>
> >>>  On 7 Apr 2023, at 00:01, Bill Johnson <
> 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> >>>
> >>>  ING isn’t a bank either.
> >>>
> >>
> >>--
> >>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 a

Re: Stop the ragging on COBOL please [was: RE: ASM call by value]

[Joe Monk]

"Too many languages lack ELSEIF and strong closure.  Fie on
the danglig ELSE!"

Now you know why COBOL programmers always indented their code ... it helps
line up the IF...ELSE structure. That was of course before VS COBOL II
(Cobol '85).

Joe

On Wed, Mar 29, 2023 at 8:01 AM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 29 Mar 2023 14:16:56 +, Robert Prins wrote:
>
> >> w..., and IBM rejected the original SHARE
> >> requirement for a CASE statement.
> >
> >But the SELECT statement that they added (before my time) later beats the
> >crap out of CASE in C & Pascal.
> >
> Pascal CASE may have a performance advantage if it can be
> implemented with an indexed branch table.  But how much does
> it matter?
>
> Isn't SELECT (I know Rexx, not PL/I) just an ELSEIF chain?
>
> Too many languages lack ELSEIF and strong closure.  Fie on
> the danglig ELSE!
>
> --
> 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: CS/CDS instruction

[Joe Monk]

Or you just could do an STFLE and check the facility bits...

Joe

On Wed, Mar 15, 2023 at 10:52 AM P H <
04843e86df79-dmarc-requ...@listserv.ua.edu> wrote:

> This doc (url below) will give you a list of what is available/supported
> on different generations of the current System z. However if you want to
> know about a specific system you have then discuss with your IBM Rep who
> will be able to give you a complete list of features (VPD) for your System.
>
> https://www.redbooks.ibm.com/abstracts/redp5157.html
>
> Regards
>
> Parwez Hamid​
> 
> From: IBM Mainframe Discussion List  on behalf
> of Ituriel do Neto <03427ec2837d-dmarc-requ...@listserv.ua.edu>
> Sent: 15 March 2023 13:30
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: CS/CDS instruction
>
> Can we detect if a specific feature is available in the current hardware?
>
>
> Best Regards
>
> Ituriel do Nascimento Neto
> z/OS System Programmer
>
>
>
>
>
>
> Em sábado, 11 de março de 2023 às 14:05:12 BRT, Paul Gilmartin <
> 042bfe9c879d-dmarc-requ...@listserv.ua.edu> escreveu:
>
>
>
>
>
> On Sat, 11 Mar 2023 00:03:06 -0800, Leonard D Woren wrote:
>
> >If some particular instruction set feature is installed, the
> >definition of ASI/AGSI is enhanced to serialize the update, making it
> >a simpler solution than a CDS loop or PLO.
> >
> >In some performance testing a while back on a z14 or z15 which I think
> >had the above serialization feature, the execution times for a very
> >large number of executions of L / AHI / ST were very close to the same
> >count of ASI.  If I recall, the ASI was a few percent slower, I guess
> >because of the serialization.  I.e., unless you're doing abnormal
> >tests as I did, you won't notice the difference.
> >
>
> From the PoOps (excerpted):
>   The storage-operand update reference for the follow- ing
>   instructions appears to be an interlocked-update reference as
>   observed by other CPUs and channel programs.
>
> • TEST AND SET
> • COMPARE AND SWAP
> (of course)
>
> • AND (NI and NIY), when the interlocked-access facility 2 is installed
> • OR (OI and OIY), when the interlocked-access facility 2 is installed
> (at last!)
>
> • ADD IMMEDIATE (ASI and AGSI), when the interlocked-access facility
>   1 is installed and the first operand is aligned on an integral
>   boundary corresponding to its size
>
> The feature-dependent instructions are treacherous.  Programmers must
> avoid them in multi-tasking code intended to be portable.
>
> I consider it bad hardware design to introduce feature-dependent
> instructions.  They should have remained invalid operations on models
> lacking the interlock facility.
>
> I believe NI and OI are primeval: they antedate multiprocessors and
> became unsafe only at the advent of multiprocessors.
>
> --
> 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
>
> --
> 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: STP timer information under z/OS?

[Joe Monk]

You can also use the STCKSYNC macro...

https://www.ibm.com/docs/en/zos/2.5.0?topic=xct-stcksync-store-clock-synchronous-service

And you can get info from CLOCKXX in SYS1.PARMLIB.

Joe

On Mon, Mar 13, 2023 at 4:08 AM Support, DUNNIT SYSTEMS LTD. <
supp...@dunnitsys.com> wrote:

> Big help! You mentioned BCPII. I found this:
>
> https://www.ibm.com/docs/en/zos/2.1.0?topic=d-parameters-13
>
> Search for the word 'timer' on the page.
>
> Who knew!
>
> --
> 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: Z15 EOM

[Joe Monk]

"The one rack z16 (aka Business Class) has not yet been announced,"

It already exists. See slide 91.

https://ibm-zcouncil.com/wp-content/uploads/2022/05/z16-Technical-Overview-50M-KennyStine.pdf

Joe





On Thu, Mar 2, 2023 at 7:45 AM Mike Shorkend 
wrote:

> The one rack z16 (aka Business Class) has not yet been announced,so I
> expect the z16+1 is still some time in the not so near future. Likewise the
> EOM for the z15.
>
> On Thu, 2 Mar 2023 at 15:34, Paul Gorlinsky  wrote:
>
> > It should also be noted that the z14 is still a supported processor for
> > zOS 3.1  ...
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> Mike Shorkend
> m...@shorkend.com
> Tel: +972524208743
>
> 
>
> 
>
> --
> 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: Need advice: rexx calling authorized asmblr w/mult parms

[Joe Monk]

The TSO call parm string is 100 characters. Is that not enough?

Joe

On Thu, Feb 16, 2023 at 7:01 AM Seymour J Metz  wrote:

> While the TSO authorized service facility will certainly do the job, I
> suspect that eventually System Rexx will become mandatory, so you might
> want to get your feet wet early on.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Mike Hochee [mike.hoc...@aspg.com]
> Sent: Thursday, February 16, 2023 1:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Need advice:  rexx calling authorized asmblr w/mult parms
>
> Looking for some advice on the simplest way to call an authorized
> assembler program from a non-compiled Rexx program under TSO/E in batch,
> with the requirement that multiple updatable parameters will be passed.
> Updating IKJTSOnn and APF authorizing whatever is not a problem.  At issue
> seems to be the following...
>
> The ADDRESS TSO CALL command appears to support only a single
> non-updatable parameter string, but does support calling an authorized
> assembler program. The LINKMVS, LINKPGM, ATTACHMVS and ATTACHPGM host
> command environments all appear to support the passing of multiple
> updatable parameters, but the Rexx Reference doc I've been reading in
> section 'Host Command Environments for Linking to and Attaching Programs',
> states that these command environments are all used to link/attach to...
> unauthorized programs.
>
> Is there a way to satisfy both requirements using the LINK* or ATTACH*
> command environments or should I be looking at System Rexx or IKJEFTSR or
> something else?  (I would prefer not to setup System Rexx if there's a
> reasonable alternative)
>
> Thanks much,
> Mike
>
>
>
> --
> 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

CZAM question

[Joe Monk]

Page 4-82 of the PoOPS says:

"If CPU power-on reset establishes the configuration, then it sets the
architectural mode to one of the following:

   -

   The ESA/390 mode (when neither the ESA/390-compatibility-mode facility
   nor the CZAM facility is installed)
   -

   The ESA/390-compatibility mode (when the ESA/390-compatibility-mode
   facility is installed)
   -

   The z/Architecture architectural mode (when the CZAM facility is
   installed)"



So, when a machine is powered on and has both CZAM and 390-CM, what is the
power-on configuration of the CPU?

Joe

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

Re: Vtam error code

[Joe Monk]

Jake,

What application is this from?

Joe

On Sun, Feb 12, 2023 at 3:24 AM Jake Anderson 
wrote:

> Hello Joe
>
> Would you please point me to the manual where it explains?
>
> On Sun, Feb 12, 2023, 1:20 PM Joe Monk  wrote:
>
> > I thnk a VTAM cmd code of 23 is an application requested cancel.
> >
> > Joe
> >
> > On Sat, Feb 11, 2023 at 10:46 PM Jake Anderson  >
> > wrote:
> >
> > > Hello
> > >
> > > One of our application was reporting the below error. I was looking
> > through
> > > the SNA and IP codes but not able to find or am ignorant about the
> below
> > > code
> > >
> > >
> > > VTAM error RtnCd:100900 Sense: Cmd:23
> > >
> > > Where exactly I can find the explanation for 100900 ?
> > >
> > > Jake
> > >
> > > --
> > > 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: Vtam error code

[Joe Monk]

I thnk a VTAM cmd code of 23 is an application requested cancel.

Joe

On Sat, Feb 11, 2023 at 10:46 PM Jake Anderson 
wrote:

> Hello
>
> One of our application was reporting the below error. I was looking through
> the SNA and IP codes but not able to find or am ignorant about the below
> code
>
>
> VTAM error RtnCd:100900 Sense: Cmd:23
>
> Where exactly I can find the explanation for 100900 ?
>
> Jake
>
> --
> 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: The Local death of DB2 z/OS --- what is the best way to preserve the data once the mainframe is gone

[Joe Monk]

1. Right click on Table, select Data > Return all Rows..

2. Result will be displayed in 'SQL Results' view, in the Result1 tab

3. Right click on data (not column heading) any where and select Export >
All Results

4. Select the CSV file format in the wizard and then save the file

5. You will have Column Names / Headings in the result

Joe

On Wed, Feb 8, 2023 at 1:45 PM Tom Longfellow <
03e29b607131-dmarc-requ...@listserv.ua.edu> wrote:

> Not dumb at all.I am between a rock and a hard place.
>
> NO resources on any servers anywhere will be committed to the preservation
> of data.
> The Mainframe will be powered off 6 months after the last primary
> application has left the building.
>
> Usability of the exported data is not managements concern.  User requests
> are not important.   ALL DATA MUST GO
>
> --
> 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: GETMAIN LOC=32

[Joe Monk]

While I appreciate the *honorable mention*,  IBM gets all the credit.

Joe

On Tue, Feb 7, 2023 at 12:16 PM Paul Edwards  wrote:

> Since this conversation has petered out, I'd just like to
> add closure (ie add the muddy water).
>
> The z/OS change that would be required to support
> negative indexing (which, while fairly uncommon, can't
> really be avoided - it's a fundamental part of how
> things work), would be to map the 4-8 GiB region onto
> 0-4 GiB (DAT/virtual storage).
>
> This has already been proven to work with z/PDOS.
>
> Note that it took me years to realize this, and it was
> Joe Monk (who posts here) who told me the problem
> could be solved with DAT.
>
> BFN. Paul.
>
>
>
>
> On Thu, 2 Feb 2023 18:55:41 -0600, Paul Edwards 
> wrote:
>
> >Why is the first thing a concern?
> >
> >The second thing is indeed a concern, and that's the thing I
> >alluded to when I said I didn't want to muddy the waters.
> >There is a solution to that, but it requires a z/OS change.
> >
> >BFN. Paul.
> >
> >
> >
> >
> >On Fri, 3 Feb 2023 00:51:08 +, Seymour J Metz  wrote:
> >
> >>My concern is that in no case does LA clear bits 0-31 while leaving the
> lower bits intact. A secondary concern is indexing with negative index
> values.
> >
> >
> >From: IBM Mainframe Discussion List  on behalf
> of Paul Edwards 
> >Sent: Thursday, February 2, 2023 7:33 PM
> >To: IBM-MAIN@LISTSERV.UA.EDU
> >Subject: Re: GETMAIN LOC=32
> >
> >No. Marking the load module as AM64 causes that to happen.
> >
> >What's the point of having documentation for what happens in
> >the different AMODEs if you think I have no control over the
> >AMODE?
> >
> >And if I instead mark the module as AM31, I will not be able to
> >clear the upper 32 bits with an LA. But I don't need to in that
> >case.
> >
> >Perhaps it would be good if you could restate your concern
> >in a simple sentence in case I'm misunderstanding.
> >
> >BFN. Paul.
> >
> >
> >
> >
> >On Fri, 3 Feb 2023 00:26:36 +, Seymour J Metz  wrote:
> >
> >>The LA instructions do *not*  force that to be the case.
> >>
> >>
> >>--
> >>Shmuel (Seymour J.) Metz
> >>http://mason.gmu.edu/~smetz3
> >>
> >>
> >>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Paul Edwards [mutazi...@gmail.com]
> >>Sent: Thursday, February 2, 2023 6:42 PM
> >>To: IBM-MAIN@LISTSERV.UA.EDU
> >>Subject: Re: GETMAIN LOC=32
> >>
> >>On Thu, 2 Feb 2023 23:33:17 +, Seymour J Metz 
> wrote:
> >>
> >>>I now of no IBM documentation to justify an expectation that the high
> halves will be zero on entry.
> >>
> >>Correct. Which is why my opening message was to add a series of LA
> >>instructions to force that to be the case myself.
> >>
> >>The main thing I was documenting was that LA was all that was needed.
> >>Previously I thought I either needed a change to the above documentation
> >>or I needed to use the non-S/370 LMH.
> >>
> >>>Chapter 2. Linkage conventions in the Assembler Services Guide is
> pretty clear that the caller expects bits 0-31 of GPRs 2-13 to be unchanged.
> >>
> >>Within a single program, bits 0-31 will indeed be unchanged,
> >>since only 32-bit instructions like LM will be used.
> >>
> >>If called by an external program, it is probably wise for the
> >>external program to not be dependent on the called program
> >>to "do the right thing".
> >>
> >>But regardless, this is up to the user to decide what they
> >>would like to do.
> >>
> >>If you insist that the called program must restore the high
> >>halves of registers and insist to be dependent on the
> >>correct behavior of the called program, then the called
> >>program must be marked AM31 at most.
> >>
> >>That's fine ... for your site and your program.
> >>
> >>I wish to have the option of doing something different. And
> >>getting a caller to preserve their own registers instead of
> >>trusting the called program is something under my control -
> >>I don't need a z/OS change.
> >>
> >>But I am interested in confirming that I haven't missed anything,
> >>before going to the effort of 

Re: Virtual tape usage

[Joe Monk]

https://www.ibm.com/docs/en/zos/2.1.0?topic=dfsms-zos-dfsmsrmm-reporting

https://www.ibm.com/docs/en/zos/2.1.0?topic=generator-sample-report-definitions

Joe

On Sun, Feb 5, 2023 at 10:15 PM Jake Anderson 
wrote:

> We use DFRMM. Is there any specific reporting batch that I can rely on ?
>
> On Mon, Feb 6, 2023, 7:49 AM Gibney, Dave <
> 03b5261cfd78-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Tape management system?
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Jake Anderson
> > > Sent: Sunday, February 05, 2023 7:45 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Virtual tape usage
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > Hello
> > >
> > > We are using DELL DLM8500. Is it possible to know from the z/OS
> > perspective
> > > on how many tapes being consumed on a monthly basis ? Is there any
> report
> > > within SMF or any facility within DLM can help me to know usage of
> > virtual
> > > tapes ?
> > >
> > > Regards
> > > Jake
> > >
> > > --
> > > 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: Searching the ASVT

[Joe Monk]

I always find it fascinating when someone tries to explain to the IBM z/OS
designers how z/OS works...

Joe

On Sun, Feb 5, 2023 at 9:16 AM Michael Stein  wrote:

> On Sun, Feb 05, 2023 at 01:34:36PM +, Peter Relson wrote:
>
> > ASVTFRST is documented as "address of first available ASVT entry". It
> > has nothing to do with "next".
>
> ASVTFRST is the address of the slot for ASID 0 which doesn't exist but
> is usefull to adjust for the fact that ASIDs start at 1 since it is
> just before ASVTENTY.
>
> > The ASVT entries form an array with the first being at ASVTENTY,
> > and each entry mapped by 4-byte field ASVTENTY.]
>
> ASVTENTY is the slot for ASID 1 and the actual start of the slots
> which (might) point to ASCBs.
>
> --
> 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: GETMAIN LOC=32

[Joe Monk]

"And
getting a caller to preserve their own registers instead of
trusting the called program is something under my control -
I don't need a z/OS change."

It doesnt work that way, because R14 will change between caller and called
program. R14 to the called program will not be the same as R14 just before
the call, because the CALL itself is an instruction...

That is why the called program restores the registers, because R14 will
point to the next instruction after the call.

Joe

On Thu, Feb 2, 2023 at 5:42 PM Paul Edwards  wrote:

> On Thu, 2 Feb 2023 23:33:17 +, Seymour J Metz  wrote:
>
> >I now of no IBM documentation to justify an expectation that the high
> halves will be zero on entry.
>
> Correct. Which is why my opening message was to add a series of LA
> instructions to force that to be the case myself.
>
> The main thing I was documenting was that LA was all that was needed.
> Previously I thought I either needed a change to the above documentation
> or I needed to use the non-S/370 LMH.
>
> >Chapter 2. Linkage conventions in the Assembler Services Guide is pretty
> clear that the caller expects bits 0-31 of GPRs 2-13 to be unchanged.
>
> Within a single program, bits 0-31 will indeed be unchanged,
> since only 32-bit instructions like LM will be used.
>
> If called by an external program, it is probably wise for the
> external program to not be dependent on the called program
> to "do the right thing".
>
> But regardless, this is up to the user to decide what they
> would like to do.
>
> If you insist that the called program must restore the high
> halves of registers and insist to be dependent on the
> correct behavior of the called program, then the called
> program must be marked AM31 at most.
>
> That's fine ... for your site and your program.
>
> I wish to have the option of doing something different. And
> getting a caller to preserve their own registers instead of
> trusting the called program is something under my control -
> I don't need a z/OS change.
>
> But I am interested in confirming that I haven't missed anything,
> before going to the effort of making sure the caller protects
> itself ... on my site.
>
> Note that the effort isn't very much, because it will be for use
> by C programs, so there is just a single C library to do the
> self-protection and then all C programs benefit.
>
> BFN. Paul.
>
> --
> 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: GETMAIN LOC=32

[Joe Monk]

I dont understand the premise here.

In AM64, LA loads 64 bits.

All of this talk of 32 bits seems to be nonsense. If the registers in
z/Arch are 64 bits, then your program is 64 bits... no? Every machine
instruction in AM64 is a 64 bit instruction... or am I missing something?

And the POPs for z/Arch says that all storage references are 64 bits
(absolute address).

How is any of this a 32 bit program?

Joe

On Thu, Feb 2, 2023 at 4:36 PM Paul Edwards  wrote:

> On Thu, 2 Feb 2023 16:38:38 +, Peter Relson  wrote:
>
> >I couldn't find the original post for this thread even in the archives,
> so I don't know what this has to do with GETMAIN, or where "LOC=32" came
> into things since the parameter is LOC=31.
>
> Here is the first post:
>
> https://listserv.ua.edu/cgi-bin/wa?A2=ind1805&L=IBM-MAIN&P=R16285
>
> >I am exactly executing in AMODE 64.
> >And so I need the high halves to be clear at all times.
> >Because I am using pure S/370 instructions.
> >
> >I'll bite. Why would you choose to run in AMODE 64 if you are trying to
> restrict yourself to S/370 instructions?
>
> So that I can potentially access the 2 GiB to 4 GiB region,
> using a "properly-written" S/370 program (that runs
> perfectly fine as AM24).
>
> >And why not even S/390 instructions, let alone z/Architecture
> instructions?
>
> You can choose whatever level you want, and the program will
> be upwardly compatible.
>
> You can actually choose S/360 if you want, capable of running
> as AM32 on a 360/67 and it will still run on AM64 on z/Arch.
>
> There are a few things the application needs to do itself,
> and I was trying to identify them.
>
> >Further, "need the high halves to be clear at all times" is not true. You
> only would need the high halves (PLUS bit 32) to be zero for a register
> used to access data and only at that point.
>
> That's not correct. You can (randomly) get access to the
> 2 GiB to 4 GiB region by using IARV64 (with or without
> a USE_2G... parameter). If you are lucky,
> you will be in a position to set the high bit of the lower
> 32 bits to 1 as part of accessing that new memory.
>
> My original post was a suggestion to get rid of that
> "randomly".
>
> But on top of that, I was looking for a z/OS change to
> guarantee the high halves were zero. And the new
> information is that I don't need that guarantee. I can
> make my S/370 applications "more-properly-written"
> by taking clear of clearing the high halves themselves,
> without being dependent on z/OS.
>
> >At a minimum, you are surely violating linkage conventions by not
> preserving the high halves of any regs 2-14 that you might use.
> >(BAKR is not a S/370 instruction; if you allow for use of BAKR then you
> can conform to linkage conventions without needing to use a zArch
> instruction such as STMG or STMH)
>
>
> There are two linkage conventions I believe:
>
> 1. When one subroutine calls another subroutine.
> 2. When one program calls another program.
>
> I assume you are only concerned about (2).
>
> And I assume you're also not concerned about the
> situation of EXEC PGM=
>
> Yes you are correct.
>
> If program A is 64-bit (e.g. lots of LG as opposed to
> 32-bit L like program B) and does a LINK EP= to program B,
> and program B is using only 32-bit instructions, running
> as AM64, and does a traditional STM to save the lower
> halves, and then does LA instructions that wipe the higher
> half of registers, and program A is dependent on those
> being preserved, then it won't work.
>
> So a new convention would be needed that before doing a
> LINK EP= or ATTACH, you need to save your own registers.
>
> If program A is unable or unwilling to do that, then program
> B will need to be marked as AM31 instead. Once again,
> assuming program B has been "properly-written" such that
> it can run in AM24, 31, 32, 64. And yes, I'm aware that the
> 360/67 (AM32 capable) is no longer manufactured or sold.
> It still exists as a historical fact and as a concept, and if you
> are able to do AM64, AM32 will work anyway.
>
> I am identifying what is required from z/OS, and what is
> required from applications, in order to support making
> S/370 (or S/360) applications "fly" (work to the maximum
> theoretical limit - including potential theoretical changes
> to z/OS) on z/Arch.
>
> Note that there are other things of interest that I haven't
> mentioned in this thread, but I am reluctant to muddy
> the waters.
>
> BFN. Paul.
>
> --
> 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: GETMAIN LOC=32

[Joe Monk]

BAKR (branch and stack) is an ESA/390 instruction.

Joe

On Thu, Feb 2, 2023 at 11:00 AM Seymour J Metz  wrote:

> > BAKR is not a S/370 instruction
>
> ?
>
> IBM Enterprise Systems Architecture/370 Principles of Operation,
> SA22-7200-0,
> <
> http://bitsavers.org/pdf/ibm/370/princOps/SA22-7200-0_370-ESA_Principles_of_Operation_Aug88.pdf>,
> p 10-5, has Branch and Stack. Or weren't you counting 370-ESA as 370?
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Peter Relson 
> Sent: Thursday, February 2, 2023 11:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: GETMAIN LOC=32
>
> I couldn't find the original post for this thread even in the archives, so
> I don't know what this has to do with GETMAIN, or where "LOC=32" came into
> things since the parameter is LOC=31.
>
> 
> I am exactly executing in AMODE 64.
> And so I need the high halves to be clear at all times.
> Because I am using pure S/370 instructions.
> 
>
> I'll bite. Why would you choose to run in AMODE 64 if you are trying to
> restrict yourself to S/370 instructions?
>
> And why not even S/390 instructions, let alone z/Architecture instructions?
>
> Further, "need the high halves to be clear at all times" is not true. You
> only would need the high halves (PLUS bit 32) to be zero for a register
> used to access data and only at that point.
>
> At a minimum, you are surely violating linkage conventions by not
> preserving the high halves of any regs 2-14 that you might use.
> (BAKR is not a S/370 instruction; if you allow for use of BAKR then you
> can conform to linkage conventions without needing to use a zArch
> instruction such as STMG or STMH)
>
> Peter Relson
> z/OS Core Technology Deisgn
>
>
> --
> 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: HMC appliance in z16

[Joe Monk]

"The SE code is running as a guest of the HMC. The two SE code instances
are clustered for high availability. One SE code runs the Primary SE the
other Alternative SE. These SEs perform data mirroring and their role can
be switched for maintenance purposes."

"Switching the Primary and Alternative SE roles is important because HMC
microcode maintenance can be performed only on the server that runs the
Alternative SE as a guest."
Page 411

https://mail.google.com/mail/u/0/#inbox/WhctKKXpSbvmbcppNmHrLvBqKDqnsVDKbdgLnvvjbLHRsMVSDDpXqJSQzgCJgwfrGMGnqGv

joe

On Sat, Jan 14, 2023 at 4:24 PM Radoslaw Skorupka <
0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:

> As it is documented, z16 supports virtual HMC appliance only. In other
> words, no more standalone PC working as HMC
> So, inside z16 cabinet there are two pizza box PC servers, both hosting
> SE and HMC.
> So, SE and HMC run virtualized on same hardware.
> Q: what is the setup of virtual machines?
> I can imagine the following:
> a) SE runs on bare metal and hosts HMC virtual machine.
> b) HMC runs on bare metal and hosts SE virtual machine.
> c) Both SE and HMC run as virtual machines, under some other hypervisor.
>
> I heard the option b) is in effect, but it doesn't seem optimal
> solution, because HMC restart implies SE temporary unavailability as well.
>
> Any clue?
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> 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: VSEn 6.3 hardware requirements

[Joe Monk]

The online stuff says the tech specs are exactly the same as z/VSE 6.3,
because it is the same source code.

https://www.21stcenturysoftware.com/license-z-vse-code-from-ibm/

Joe

On Sat, Jan 14, 2023 at 4:17 PM Radoslaw Skorupka <
0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:

> I'm looking for technical information about VSEn 6.3, precisely hardware
> requirements like max. memory supported, max. CPs supported/used, etc.
>
> Note: VSEn 6.3 is new incarnation of zVSE, but now it is produced by
> 21st Century Software.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> 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: Question and CZAM and IPL

[Joe Monk]

Word = 4 bytes
Doubleword = 8 bytes
Quadword = 16 bytes

Joe

On Wed, Jan 11, 2023 at 9:07 AM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 11 Jan 2023 14:03:24 +, Seymour J Metz wrote:
>
> >"The current PSW is replaced by a 16-byte PSW
> >formed from the contents of the doubleword at the
> >location designated by the second-operand address.
> >Figure 4-3 on page 4-8 illustrates the contents of the
> >second operand."
> >
> "doubleword"?
>
> --
> 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: Question and CZAM and IPL

[Joe Monk]

Ok, but the machine immediately changes it to a 16-byte PSW before it uses
it correct?

Joe

On Sun, Jan 8, 2023 at 10:33 PM Jim Mulder  wrote:

>   The IPL PSW provided  by software is always 8 bytes.
> There is no provision for providing a 16 byte PSW.
>
> Jim Mulder
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Joe Monk
> Sent: Sunday, January 8, 2023 4:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Question and CZAM and IPL
>
> When a z/arch machine has CZAM installed, is it possible to use a short
> PSW to IPL. Or, does the short PSW always become a long PSW before IPL, so
> it is better to use a long PSW to start with?
>
> In POPs, it says on page 3-75:
>
> "When the CZAM facility is installed, the IPL PSW has the short-PSW
> format, as shown in Figure 4-3 on page 4-8."
>
> But on page 4-8, it says:
>
> "Note: The term short PSW refers only to the eight-byte entity in storage.
> The actual PSW used by the CPU is the 16-byte register illustrated in
> Figure 4-2."
>
> Joe
>
> --
> 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

Question and CZAM and IPL

[Joe Monk]

When a z/arch machine has CZAM installed, is it possible to use a short PSW
to IPL. Or, does the short PSW always become a long PSW before IPL, so it
is better to use a long PSW to start with?

In POPs, it says on page 3-75:

"When the CZAM facility is installed, the IPL PSW has the short-PSW format,
as shown in Figure 4-3 on page 4-8."

But on page 4-8, it says:

"Note: The term short PSW refers only to the eight-byte entity in storage.
The actual PSW used by the CPU is the 16-byte register illustrated in
Figure 4-2."

Joe

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

Re: Broadcom

[Joe Monk]

https://community.broadcom.com/mainframesoftware/communities/all-discussions/viewthread?GroupId=2035&MessageKey=8eec743a-6017-4471-bbf9-d16d1caa9ca1&CommunityKey=c66cac08-5724-4f3e-8734-56dffb11f900

Joe

On Fri, Jan 6, 2023 at 1:32 PM Steve Beaver  wrote:

> Does anyone know if Broadcom is staying with Chorus or move to zOSMF?
>
>
>
>
>
> Regards
>
> Steve
>
>
> --
> 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: Computers

[Joe Monk]

Not true.

The 3350 could run in 3330 compatibility mode and could be used with OS/360.

Joe

On Sun, Dec 11, 2022 at 3:45 PM Seymour J Metz  wrote:

> Yes, but not OS/360.
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of David Spiegel <0468385049d1-dmarc-requ...@listserv.ua.edu>
> Sent: Sunday, December 11, 2022 3:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Computers
>
> Hi R'Shmuel AMV"SH,
> I'm pretty sure that I ran IEHDASDR (OS/VS2 V3.8) to Back Up 3350s.
>
> Regards,
> David
>
> On 2022-12-11 15:17, Seymour J Metz wrote:
> > That may have been OS/VS only; I vaguely recall a PRPQ to add 3350
> support to OS/360.
> >
> > 
> > From: IBM Mainframe Discussion List  on
> behalf of David Spiegel <0468385049d1-dmarc-requ...@listserv.ua.edu>
> > Sent: Sunday, December 11, 2022 3:02 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Computers
> >
> > Hi R'Shmuel AMV"SH,
> > IIRC, IEHDASDR supported 3350.
> >
> >
> > Regards,
> > David
> >
> > On 2022-12-11 11:52, Seymour J Metz wrote:
> >> IEHDASDR was part of OS/360, OS/VS1 and OS/vs2, and continued to exist
> in MVS for lo these many releases. However, Direct Access Storage Dump
> Restore (DASDR), 5740-UT1, is a separate program, with a separate dump
> format, and was never part of any of them; you had to order and install it
> separately. Oh, the DASDR dump format was also not compatible with DF/DSS,
> 5740-UT3.
> >>
> >> As I recall, IEHDASDR did not support 3350, much less 3375, 3380 or
> 3390.
> >>
> >>
> >> --
> >> Shmuel (Seymour J.) Metz
> >>
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3&data=05%7C01%7Csmetz3%40gmu.edu%7C85e25f6376b744e0cd3108dadbb5a0cb%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638063870375757633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=f%2FhyR4crGpC8dHoKJrnfbQymUN0YRTjDxvQ6pag9jxI%3D&reserved=0
> >>
> >> 
> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of David Spiegel [0468385049d1-dmarc-requ...@listserv.ua.edu]
> >> Sent: Friday, December 9, 2022 1:53 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Computers
> >>
> >> IEHDASDR  was part of MVT (early '70s)
> >> DF/DSS came much later (maybe 10 years?)
> >>
> >> On 2022-12-09 13:12, Seymour J Metz wrote:
> >>> I believe that DASDR and DF/DSS came later.
> >>>
> >>>
> >>> --
> >>> Shmuel (Seymour J.) Metz
> >>>
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3&data=05%7C01%7Csmetz3%40gmu.edu%7C85e25f6376b744e0cd3108dadbb5a0cb%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638063870375757633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=f%2FhyR4crGpC8dHoKJrnfbQymUN0YRTjDxvQ6pag9jxI%3D&reserved=0
> >>>
> >>> 
> >>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Steve Beaver [st...@stevebeaver.com]
> >>> Sent: Tuesday, December 6, 2022 7:29 AM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Re: Computers
> >>>
> >>> DSS.  Data Set Services
> >>>
> >>> Sent from my iPhone
> >>>
> >>> No one said I could type with one thumb
> >>>
>  On Dec 6, 2022, at 06:21, Jay Maynard  wrote:
> 
>  OK, this is a new one on me. What's DSS?
> 
> > On Tue, Dec 6, 2022 at 6:09 AM Seymour J Metz 
> wrote:
> >
> > MVS/SE installed on an OS/VS2 base; for R1 it was 3.7 with
> prerequisite
> > selectable units and for R2 it was 3.8 with prerequisite selectable
> units.
> > In each case a prerequisite SU killed DSS. MVS/SP replaced MVS/SE
> >
>  --
>  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: Computers

[Joe Monk]

http://www.bitsavers.org/pdf/ibm/370/OS_VS2/Release_3.0_1975/

Joe

On Fri, Dec 2, 2022 at 5:42 AM David Spiegel <
0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:

> Hi Leonard,
> You said: "... That computer center had MVS 3.0 running in the mid
> 1970s. ..."
> Is "MVS 3.0" a typo? (I do not recall ever hearing of MVS 3.0.)
>
> Thanks and regards,
> David
>
> On 2022-12-02 02:15, Leonard D Woren wrote:
> > Bill Hitefield wrote on 11/30/2022 10:39 AM:
> >> In college we had an IBM 1130 in the computer lab. Those of us
> >> working in the lab discovered an AM radio placed near the console
> >> switches made odd noises when you ran Fortran programs and set the
> >> radio to a specific "station". Further investigation revealed you
> >> could change the tone of the noise by using the "e to the x" function
> >> and varying the value of "x". Our goal in life then became to play
> >> "Smoke on the Water" using that radio. The temp wasn't too great, but
> >> you could recognize the main riff!
> >>
> >> Bill Hitefield
> >> Dino-Software Corporation
> >> 800.480.DINO
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dino-software.com%2F&data=05%7C01%7C%7C3be70de2f0a4461a031508dad43519eb%7C84df9e7fe9f640afb435%7C1%7C0%7C638055621915923673%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HYCO5ydHeECYap0cCUN2KL8RMGsSYHnM38onglYyJc8%3D&reserved=0
> >>
> >>
> >
> > I don't remember it very well, but I think the same could be done to
> > some extent on some 360 models.
> >
> > In the mid-1970s, a college friend had a job as an off-hours computer
> > operator at RAND (amusingly, where that 1970 film was made).  He
> > wrote, and a musical friend tuned, a program which played music on a
> > 2400 series tape drive by writing various length blocks -- the shorter
> > the repeated block, the higher the note.  I think one of their 2 songs
> > was Puff the Magic Dragon.  It was just hilarious to hear recognizable
> > music from a tape drive.  The program wore out tapes pretty quickly
> > though because all those short blocks were tough on the tape.  One
> > long channel program IIRC to keep the music from pausing when a
> > different job was dispatched.
> >
> > Footnote:  That computer center had MVS 3.0 running in the mid 1970s.
> > It was the first time that I saw MVS with lots of new stuff compared
> > to MVT 21.  But no TSO -- they ran Wylbur.
> >
> >
> > /Leonard
> >
> >
> > --
> > 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: Bytes in a 3390 track - reason for the question

[Joe Monk]

i was just getting ready to say this same thing.

The 3390 reference shows that for a 3120 byte block, only 15 blocks fit on
a track, with a 16% space waste.

Your best bet is to use TRKCALC...
https://www.ibm.com/docs/en/zos/2.4.0?topic=instructions-performing-track-calculations-trkcalc-macro

Joe

On Thu, Nov 24, 2022 at 11:25 AM Joel C. Ewing  wrote:

> Subtracting the logical blocksize from either of those capacity numbers
> as you describe will not give correct results for blocks per track.  The
> only accurate way to determine how many blocks will fit on a 3390 track
> is to use the formulas from the 3390 Reference Summary (mentioned in
> previous post) to compute the number of 34-byte cells required to write
> the block and see if enough of the 1729 cells in the track remain.   For
> fixed-sized blocks of length requiring "x" cells, the number of blocks
> per track would be  floor(1729/x) .
>
> Alternatively,  there is a table in the 3390 Reference Summary on page
> 12 showing the minimum and maximum block sizes vs number of blocks per
> track.  It only has 86 rows (a blocksize of 1 byte only gets you 86
> usable bytes per track!), so you could store the Min, Max, and Records
> columns of that entire table in a program and look up any blocksize to
> see which which row min/max includes that blocksize and extract the
> blocks/track from the Records row of the table.
>
> If your object is to report how much resource the datasets are
> consuming, then tracks allocated makes the most sense.
>
> If your object is to report how much useful data is in the dataset, then
> the blocksize becomes potentially useful.  If you can get the
> last-track-used you can compute the number of actual blocks in the
> dataset within an accuracy of blocks-per-track - 1.
>
> The actual useful data per track vs best-case usage might also be useful
> if a sub-optimal blocksize has been chosen.
>
>  Joel C Ewing
>
> On 11/24/22 10:14, John Gateley wrote:
> > The reason for asking the question about bytes on a track is that I am
> writing programs to report on all disk datasets.
> > The first program looks at all on-line disk packs and extracts all
> format 1, 3, 8 and 9 DSCBs while also providing a summary of space
> available/used on each disk (similar to VTOC on CBT file 112).
> > The second program produces information for all datasets. If the
> secondary allocation is in blocks then that means the primary was also and
> I want to output the allocation like this BLK(00060,00020).
> > To do this I subtract the block size from 56664 repeatedly until the
> remainder is less than the block size which gives me the number of blocks
> in a track, multiply this by the primary allocation in tracks should give
> me the figure I want.
> > Except it doesn't.
> >
> > For the format 1 DSCB below ISPF 3;4 reports BLK(00060,00020) and my
> program BLK(00072,00020).
> > With a blocksize of 3120 there are 18 blocks per track and 4 tracks are
> in use. 3 of them must be full so that gives 54 blocks meaning there are
> only 6 on the final track.
> >
> > The dataset is not extended format, PDSE, HFS or VSAM so I think I need
> to look at DS1TRBAL, I subtracted 32266 from 56664 and worked out how many
> blocks would fit, I get 7 not 6.
> >
> > Alternatively, if I use 55996 I get 17 blocks per track meaning there
> are 9 on the last track and I get 7.
> >
> > I'm obviously missing something, and I am hoping someone can tell me
> what?
> >
> > DS1DSNAM  DSN1.SRCLIB.DATA
> > DS1FMTID  1
> > DS1DSSN   DB2C06
> > DS1VOLSQ  0001
> > DS1CREDT  78003A
> > DS1EXPDT  00
> > DS1NOEPV  01
> > DS1NOBDB  00
> > DS1FLAG1  00
> > DS1SYSCD  IBMOSVS2
> > DS1REFD   7A0148
> > DS1SMSFG  80
> > DS1SCXTF  80
> > DS1SCXTV  0FA04000
> > DS1DSORG  0200
> > DS1RECFM  90
> > DS1OPTCD  00
> > DS1BLKL   0C30
> > DS1LRECL  0050
> > DS1KEYL   00
> > DS1RKP
> > DS1DSIND  80
> > DS1SCAL1  50
> > DS1SCAL3  14
> > DS1LSTAR  15
> > DS1TRBAL  7E0A32266
> > DS1TTTHI  00
> > DS1EXT1   010C000B000C000E
> > DS1EXT2   
> > DS1EXT3   
> > DS1PTRDS  00
> >
> > Data Set Name . . . . : DSN1.SRCLIB.DATA
> >
> > General Data  Current Allocation
> >   Management class . . :Allocated blocks  . : 60
> >   Storage class  . . . :Allocated extents . : 1
> >Volume serial . . . : DB2C06 Maximum dir. blocks : 20
> >Device type . . . . : 3390
> >   Data class . . . . . :
> >Organization  . . . : POCurrent Utilization
> >Record format . . . : FB Used blocks . . . . : 7
> >Record length . . . : 80 Used extents  . . . : 1
> >Block size  . . . . : 3120   Used dir. blocks  . : 1
> >1st extent blocks . : 60 Number of members . : 0
> >Secondary blocks  . : 20
> >Data set name type  : PDS   Dates
> >Data set encryption : NO Crea

Re: Storage protection keys

[Joe Monk]

I know this is super old information ... but given the discussion so far,
it seems reasonable to at least apply the same concept ...

"The storage-protect unit has a 64 x 8 monolithic storage protection stack
that applies to main storage locations zero through 131,072 (in sequential
blocks of 2,048 bytes). Additional stacks are provided in the CPU when main
storage capacity extends from 131,072 bytes to 524,288 bytes. Above 524,288
bytes, storage protect is located in the Power Frame (03) and is a mix of
64 x 8 and 64 x 18 monolithic storage cards."

http://www.bitsavers.org/pdf/ibm/370/fe/3145/SY24-3581-4_3145_Processor_Theory_Maintenance.pdf

Joe

On Wed, Nov 23, 2022 at 6:56 AM Jay Maynard  wrote:

> Well, you have to store the key *somewhere* when the page is paged out. But
> you're right, the page table entry isn't it. I don't know what I was
> thinking.
>
> I'm sure that VSM maintains its own table of correspondence between virtual
> storage addresses and storage key, so the key can be applied to the page
> upon page-in, but I don't know the details.
>
> On Wed, Nov 23, 2022 at 4:12 AM Ian Worthington <
> 047bb6801512-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Many thanks for that Jay.  This would certainly seem the logical place to
> > store it.
> >
> > I'm still a bit confused though.  The pop section on Page-Table Entries
> > (page 3-51 in the 13th edition...) does not mention this (though it does
> > have a unused byte at the end).  If the intention is to make the storage
> > key unaddressable (p 3-9) and alterable only via SSKE (which, given the
> > need to propagate it to the caches of all processers would seem make
> sense)
> > would it not be contraindicated to use this byte to keep it in?
> >
> > I'd love to see a paper or article which discusses how this is done,
> > though, like cpu design, I appreciate it may well change from model to
> > model.
> >
> >
> > Best wishes
> >
> > Ian ...
> >
> > On Tuesday, November 22, 2022 at 05:28:37 PM GMT+1, Jay Maynard <
> > jaymayn...@gmail.com> wrote:
> >
> >  They are held in the page tables and set in the hardware - in extra
> memory
> > that is not software accessible except through a few supervisor-level
> > instructions such as SSK (set storage key) - when the page is assigned
> to a
> > real storage frame.
> >
> > On Tue, Nov 22, 2022 at 10:24 AM Ian Worthington <
> > 047bb6801512-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > I don't think the storage keys (and their friends) are held in the page
> > > tables though.
> > >
> > >
> > > Best wishes / Mejores deseos /  Meilleurs vœux
> > >
> > > Ian ...
> > >
> > >On Tuesday, November 22, 2022 at 05:04:08 PM GMT+1, Jay Maynard <
> > > jaymayn...@gmail.com> wrote:
> > >
> > >  Each page table entry has a byte associated with it that stores the
> key,
> > > as
> > > well as the referenced and changed bits.
> > >
> > > And yes, 4K page tables do soak up lots of memory, which is why later
> > OSes
> > > use 1M or 2M pages.
> > >
> > > On Tue, Nov 22, 2022 at 9:22 AM Ian Worthington <
> > > 047bb6801512-dmarc-requ...@listserv.ua.edu> wrote:
> > >
> > > > Does anyone know where the storage protection keys are kept?  It
> seems
> > > > that the processors maintain recent keys in the TLB to be accessed by
> > the
> > > > DAT,  but where do they live when they're not in the TLB?  Surely we
> > need
> > > > one byte per 4k page per address space, which could be quite a bit of
> > > > storage, so I'm assuming this has to be above the bar now? I can't
> see
> > > any
> > > > information in the pop about this.
> > > >
> > > >
> > > > Best wishes / Mejores deseos /  Meilleurs vœux
> > > >
> > > > Ian ...
> > > >
> > > >
> --
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send email to lists...@listserv.ua.edu with the message: INFO
> IBM-MAIN
> > > >
> > >
> > >
> > > --
> > > Jay Maynard
> > >
> > > --
> > > 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
> > >
> >
> >
> > --
> > Jay Maynard
> >
> > --
> > 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
> >
>
>
> --
> Jay Maynard
>
> --

Re: IBM sues Micro Focus, claims it copied mainframe software • The Register

[Joe Monk]

Not sure that this is a winnable lawsuit though.

The architecture of a file (and the data therein) that is only needed to
run a product is not copyright protected. So copying the WSBIND
file doesnt necessarily amount to a copyright violation.

Joe

On Tue, Nov 22, 2022 at 10:10 AM Bob T Roller <
044ef325f6c3-dmarc-requ...@listserv.ua.edu> wrote:

> Not surprised. They lost their preferred vendor status with IBM a year or
> so ago. Because of their tie up with Amazon.
>
> Sent from Proton Mail for iOS
>
> On Tue, Nov 22, 2022 at 9:25 AM, Mark Regan  wrote:
>
> > https://www.theregister.com/2022/11/22/ibm_sues_micro_focus_for
> >
> > ​Regards,
> >
> > Mark Regan, K8MTR General, EN80tg
> > CTO1 USNR-Retired (1969-1991),
> >
> > RUENAAA/CNO WASHINGTON DC//OP-009QCP
> >
> > Nationwide Insurance, Retired, 1986-2017
> > z/OS Network Software Consultant (z NetView, z/OS Communications Server)
> > Contractor, Checks & Balances, Inc.
> > Email: marktre...@gmail.com 
> > LinkedIn: https://www.linkedin.com/in/mark-t-regan
> >
> > --
> > 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: Storage protection keys

[Joe Monk]

"Storage keys are not part of addressable storage."

http://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf page 3-9

Joe

On Tue, Nov 22, 2022 at 9:22 AM Ian Worthington <
047bb6801512-dmarc-requ...@listserv.ua.edu> wrote:

> Does anyone know where the storage protection keys are kept?  It seems
> that the processors maintain recent keys in the TLB to be accessed by the
> DAT,  but where do they live when they're not in the TLB?  Surely we need
> one byte per 4k page per address space, which could be quite a bit of
> storage, so I'm assuming this has to be above the bar now? I can't see any
> information in the pop about this.
>
>
> Best wishes / Mejores deseos /  Meilleurs vœux
>
> Ian ...
>
> --
> 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: TNZ 3270 Emulator: Any Experiences?

[Joe Monk]

Dont forget ZOC!

Joe

On Fri, Nov 18, 2022 at 10:34 AM Sebastian Welton 
wrote:

> >And now through consolidation, There's really only two TN3270 vendors
> left: Micro Focus and IBM!
> >
>
> I think people have mentioned that there are quite a few TN3270 clients
> still out there, on my (Windows) system I have the following installed as
> each has something I require on it or can only use it on certain systems:
>
> PCOM; - rather old version but I quite like it
> Vista TN3270 - emulator of choice
> wc3270 - the Windows version of x3270
> MochaSoft - the only emulator I've come across that doesn't have IND$FILE
> support but I have to have it
>
> As for other opensource, I think everyone knows the x3270 range but I've
> been using this one on Linux on and off for quite a while:
>
> https://github.com/PerryWerneck/pw3270
>
> pw3270 is a modern, GTK-based, completely free tn3270 emulator.
>
> Created originally for Banco do Brasil, it's now an official Brazilian
> Government Public Software project, and is used worldwide.
>
> Sebastian
>
> --
> 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: MVS/370 System Initialization Library?

[Joe Monk]

http://www.bitsavers.org/pdf/ibm/370/OS_VS2/Release_3.7_1977/GC28-0681-2_OSVS2_SPL_Initialization_and_Tuning_Guide_VS2_Release_3.7_3rd_ed_197601.pdf

Joe

On Thu, Nov 10, 2022 at 6:30 AM Seymour J Metz  wrote:

> Does anybody have a link for a scanned copy of System Initialization
> Library for MVS/370 (anything from OS/VS2 R2 through MVS/SP V1) that I can
> cite for wikipedia?
>
> Also, does anybody remember when addition nucleus load modules came in?
> When the parmlib member replaced the csect for selecting what to load?
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> --
> 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: Integrated Catalog record layout

[Joe Monk]

The mapping macro should be in SYS1.MACLIB.

Joe

On Sat, Oct 22, 2022 at 7:26 AM Willy Jensen 
wrote:

> I'm ok wth the layout of the SMF record as such, what I am looking for is
> the layout of the field SMF61CRC.
>
> --
> 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: Integrated Catalog record layout

[Joe Monk]

SMF record layouts are in the MVS SMF manual ...
https://www.ibm.com/docs/en/zos/2.5.0?topic=mvs-zos-system-management-facilities-smf

The record layout is here:
https://www.ibm.com/docs/en/zos/2.5.0?topic=rm-headerself-defining-section-51

When SMF61TYP = "A", that is a non-vsam record. The DSN is in SMF61ENM. The
Catalog is in SMF61CNM, which you can read to get the volser.

Joe

On Sat, Oct 22, 2022 at 4:50 AM Willy Jensen 
wrote:

> Hi, anybody knows where to find the mapping of Integrated Catalog records?
> I am looking at SMF type 61 and at the end it says 'New catalog record for
> defined entry', but doesn't say where to find the mapping. I am primarily
> looking for volser information for non-vsam datasets. I have found the
> position by printing a few records and eye-balling the result, but I would
> like something a bit more official. I did look at the CSI interface
> returned info, but it doesn't match up with what I see in the SMF record.
> I couldn't find any IBM documentation nor anything in the internet in
> general.
>
> --
> 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: COBOL - z/OS 2.1 vs 2.4

[Joe Monk]

Can you post a CEDF trace?

Joe

On Mon, Oct 3, 2022 at 2:19 PM Crusty Old Guy 
wrote:

> I have further information from the programmers.
>
> These are CICS programs. The programs do not initialize their working
> storage.  I'm told everything is fine under z/OS 2.1.
>
> Under z/OS 2.4, they are getting garbage in the COMMAREA. They want to
> know why it runs OK under 2.1.
> I have not found an answer for them in the migration guide.  Can anyone
> help?
>
> COG
>
> --
> 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: Is there such a thing as JCL to transfer files using https?

[Joe Monk]

I would imagine so.

Just use BPXBATCH and supply the https commands.

Joe

On Sat, Oct 1, 2022 at 10:53 AM Billy Ashton  wrote:

> Hi everyone! You have been so helpful in the past to help me with
> getting my file transfers working with sftp, and now, we have a manager
> who wants to explore using https in batch like we do online in our
> browsers. He thinks we can secure our ports better if we are not using
> as many. We would be using it to move files back and forth with a couple
> of our major business partners.
>
> Is such a thing possible? What do I need to think about if this is
> possible? Does anyone have any sample JCL they have used and would be
> able to share with me?
>
> I have tried to research this, but really haven't found anything useful
> (I guess this should be a clue).
>
> Thank you and best regards,
> Billy Ashton
>
> --
> 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: zOS 1.13 (really) how copy MVS loadmod from ZFS to PDSE

[Joe Monk]

According to the z/os unix system services command guide:

"An executable file copied from the file system into an MVS data set is not
executable under MVS. Some required directory information is lost during
the copy. See z/OS UNIX System Services User's Guide

 for a discussion of copying executable files."

Joe

On Tue, Sep 27, 2022 at 3:31 PM Nightwatch RenBand 
wrote:

> This is a cross-post from MVS-OE since not much activity there...
> Keeping zOS alive at this late date and need to update  to JAVA8 in order
> to accomodate SCRT 29.
> The JZOS module is there in the zfs and if I can copy it to a PDSE I should
> be able to run JZOS
> But I cannot get a valid zos loadmod copied.
> I have tried:
> > from OMVS cp -X  this "works" but PDSE load mod will not execute, gets
> S-0C1
> > OPUT OGET (note that zOS 1.13 does not include OGETX as far as I can
> tell).
> > Also tried the linkedit from the USS Systems services manual. Linked, but
> would not execute. Probably an entry point problem.
> This shouldn't be this hard, really
>
> --
> 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: System parmlib concat

[Joe Monk]

"The SYS1.PARMLIB data set itself can be blocked and can have multiple
extents, but it must reside on a single volume. The parmlib concatenation
used at IPL must be a PDS. However, after IPL you may issue a SETLOAD
command to switch to a different parmlib concatenation which contains
PDSEs."

https://www.ibm.com/docs/en/zos/2.5.0?topic=time-description-use-parmlib-concatenation

Joe

On Fri, Sep 23, 2022 at 11:04 PM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> Hi,
>
> I was asked a question today that I have no idea what to answer to it.  I
> was asked if it is possible or advisable to change the system parmlibs from
> PDS to PDSE and if there was nay benefit to doing it.
>
> My first reaction was that it would be a bad idea, and that PDSe's might
> not be supported at actual IPL, but I'm not aware of any real
> restrictions.  I know that they are supported later int he IPL process, but
> I have zero idea if you can make the system parmlib a PDSE.
>
> Does anyone know if it's allowed or where I would find information on if
> it's disallowed and why?
>
> It's not vitally important, but it has been bugging me since I was asked
> earlier today.
>
> Brian
>
> --
> 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: z/OSMF PSWI

[Joe Monk]

>From Marna Walle, back on July 20, 2022:

"As for the sizes, for z/OSMF ServerPac we have increased the shipped free
space to 40% per data set, and with linklst data sets have zero secondary.
This is an increase over the prior free space size we used to provide, in
hopes that will help for the time being.  This was done because we don't
have the ability to re-size today in z/OSMF.

Now...I would like to look at the data set size problem in a larger context
- in order to understand where to solve this problem.  More than ever, we
have been shipping Continuous Delivery PTFs.  Many of these PTFs are quite
large, and occur over the life of a release.  This can put quite a lot of
pressure on the size of the target and DLIB data sets being able to
accommodate these updates for every service install episode.  I am
wondering, if it might be of better use to have the capability of
accommodating the need for more space in a more ongoing manner?  Meaning,
installing a release for a first time - even with enlarging the data sets
with some predictive percentage (50%, 100%, 200%?) - still doesn't
completely help with running out of space in some data sets or even volumes
continually, and could result in some data sets being overly and
unnecessarily large.  Would it be better if z/OS itself was able to assist
better when the problem occurred in a targeted and timely fashion?  Do you
feel that if z/OSMF Software Management provided this ability to one-time
increase the size of allocated target and DLIBs, that would conclusively
solve your space problems for these data sets?"

Joe

On Wed, Sep 21, 2022 at 3:29 PM Michael Babcock 
wrote:

> We are installing z/OS 2.5 via z/OSMF and are using the Modify Deployment
> screens.  We can easily change the volumes, HLQs, etc, but wanted to modify
> the Primary and/or secondary allocation and don’t see a way to do that.
>
> We have a case opened with IBM and have been told there is no way to do
> that and no plans for it in the future.   What?We could do that with
> the ServerPac, why not with z/OSMF?   I was under the impression that
> z/OSMF would provide most functions that ServerPac provided.
>
> So, is that capability not going to be provided?
>
>
> --
> Michael Babcock
> OneMain Financial
> z/OS Systems Programmer, Lead
>
> --
> 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 courses

[Joe Monk]

My GE 1101 (1st level Gen Engineering) class was PASCAL programming on a
DecSystem running TOPS20.

Never used it again.

Joe

On Sat, Sep 17, 2022 at 3:55 PM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> ME Too!!   I can't remember ever using my Fortran after the class was
> over.  Luckily the instructor also offered an assembler class that he
> taught "on the side" for an extra $50.  I still use the stuff he taught us
> almost every day.
>
> Brian
>
> On Sat, 17 Sep 2022 19:29:01 +, Farley, Peter x23353 <
> peter.far...@broadridge.com> wrote:
>
> >My experience was the opposite of yours over a few more years (50).  I
> learned assembler early via OJT at one of my first permanent jobs, and got
> to use it more and more as I moved to other employers.  Knowing assembler
> got me in the door at more than one of those employers.
> >
> >It was the FORTRAN I learned in engineering college that I never used
> anywhere else.
> >
> >Peter
> >
> >-Original Message-
> >From: IBM Mainframe Discussion List  On Behalf
> Of Bob T Roller
> >Sent: Saturday, September 17, 2022 3:17 PM
> >To: IBM-MAIN@LISTSERV.UA.EDU
> >Subject: Re: Assembler courses
> >
> >Learning assembler is like taking latin in high school. It might help you
> on Jeopardy but will not be of much help in real life. I took assembler in
> college & never used it and never worked at an employer that used it.
> That’s a dozen+ employers over 45 years.
> >
> >Sent from Proton Mail for iOS
> >
> >On Fr , Sep 16, 2022 at 10:11 PM, Gary Weinhold  wrote:
> >
> >> To help a person who has COBOL and C language experience learn to write
> assembler, I would like them to learn from the start both reentrant and
> baseless coding techniques. Is there training available that assumes the
> instruction set available on the z12 is the starting point and that teaches
> reentrancy as the norm?
> >>
> >> (Cross-posted to IBM-Main and Assembler-list)
> >>
> >> Gary Weinhold
> >> Senior Application Architect
> >> DATAKINETICS | Data Performance & Optimization
> >> Phone:+1.613.523.5500 x216
> >> Email: weinh...@dkl.com
> >--
> >
> >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
>
> --
> 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 courses

[Joe Monk]

I would suggest you start by writing subroutines that can be called  by a
COBOL program. This is how I learned.

Take a COBOL driver program, and instead of writing paragraphs to do the
functions, call an assembler routine. This will help you to learn linkage.
Learn to process passed variables, etc.

Once you have that down, changing to re-entrancy and baseless coding is
merely a matter of changing subroutines you already have and know.

Joe

On Fri, Sep 16, 2022 at 9:12 PM Gary Weinhold  wrote:

> To help a person who has COBOL and C language experience learn to write
> assembler, I would like them to learn from the start both reentrant and
> baseless coding techniques.  Is there training available that assumes the
> instruction set available on the z12 is the starting point and that teaches
> reentrancy as the norm?
>
> (Cross-posted to IBM-Main and Assembler-list)
>
>
>
>
>
> Gary Weinhold
> Senior Application Architect
> DATAKINETICS | Data Performance & Optimization
> Phone:+1.613.523.5500 x216
> Email: weinh...@dkl.com
> Visit us online at www.DKL.com
> E-mail Notification: The information contained in this email and any
> attachments is confidential and may be subject to copyright or other
> intellectual property protection. If you are not the intended recipient,
> you are not authorized to use or disclose this information, and we request
> that you notify us by reply mail or telephone and delete the original
> message from your mail system.
>
>
>
> --
> 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

ibm-main@listserv.ua.edu

[Joe Monk]

Since $ is a valid character in a SYSNAME, I dont think you want to make
that change.

Joe

On Sun, Sep 11, 2022 at 11:44 PM Lizette Koehler 
wrote:

> I have a coworker saying we should change our /&SYSNAME/etc/..   To
> /$SYSNAME/etc/.
>
>
>
> I am not familiar with coding this way
>
>
>
> Could someone provide a cons vs pros (simple words please) on which is
> needed, or used or preferred?
>
>
>
> 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: DS6800 array - not booting

[Joe Monk]

"After powering on the enclosure, the information indicator flashes to
indicate that the system is initializing and is not yet ready to be
accessed by either the management console or host systems. Once the
flashing amber light turns off, initialization is complete and the system
is ready for I/O.

"CAUTION:

"Upon power on, a discovery process is initiated to detect all hardware.
This process can take an extensive amount of time, depending on the number
and type of attachments. You must wait until this process is complete
before initiating any other processes."

GC26-7925  Installation, Troubleshooting, and Recovery Guide

Joe

On Sat, Sep 3, 2022 at 4:37 PM Adam Stouffer <
0453defb5de1-dmarc-requ...@listserv.ua.edu> wrote:

> Hello all. I'm one of the volunteers at the Large Scale Systems Museum
> in New Kensington, Pennsylvania. Some of you might be familiar with us
> or even taken a tour. A generous company has donated a decommissioned
> DS6800 array with disks. We would like to get this configured for our
> systems but have run into a road block. It powers up but neither
> controller shows any signs of life. No output from either console port
> and no ethernet links. The orange system information light is flashing
> and all the documentation says this light should either be on solid or
> off. No mention of it flashing. The drives all spin up in groups and the
> battery lights indicate they are charged. The ficon link lights also
> flash. It just seems like the controllers are not booting. Has anyone
> seen a flashing system information light or know how to troubleshoot
> further? Thanks.
>
> --
> 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: ELAX DRAWDOWN??

[Joe Monk]

Isnt ELAX IBM rational products?

Joe

On Wed, Aug 31, 2022 at 9:04 AM Steve Thompson  wrote:

> Any one heard of this or what it is?
>
> I got asked about it and I've never heard of it, and it is
> supposedly an IBM product and I can't find doc on it in an IBM site.
>
> Regards,
> Steve Thompson
>
> --
> 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: IDC3009I & IDC1566I with a weird dsn

[Joe Monk]

Look at the messages:

IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFF-5
IDC1566I ** .|. ...8..U...2. NOT LISTED

Where is the core trash in 1566 coming from? 3009 return code 50 is VVDS
unavailable.

Joe

On Tue, Aug 30, 2022 at 12:27 PM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 30 Aug 2022 11:35:55 -0500, Joe Monk wrote:
>
> >Might be this: https://www.ibm.com/support/pages/apar/OA57619
> >
> >Users of CSI and LISTCAT Level may receive inconsistent errors
> >on entries that have no problem otherwise due to uninitialized
> >workarea data.
> >
> The APAR says:
>  Local fix
> fix errant entries, re-run listcat
>
> ???  Since there are PTFs, I believe the "uninitialized workarea data"
> belong to
> IDCAMS, not the user.  The user needs detailed "Local fix" information.
>
> --
> 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: IDC3009I & IDC1566I with a weird dsn

[Joe Monk]

Might be this: https://www.ibm.com/support/pages/apar/OA57619

Users of CSI and LISTCAT Level may receive inconsistent errors
on entries that have no problem otherwise due to uninitialized
workarea data.


Joe

On Tue, Aug 30, 2022 at 9:04 AM Jack Zukt  wrote:

> Hi all,
>
> Another situation that come up. Is anyone of you familiar with these
> messages:
>
> IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLFF-5
> IDC1566I ** .|. ...8..U...2. NOT LISTED
>
> As far as I can see, there is not one dataset with such a name on any of
> the available DASD. And yet I have 34 of those messages across 7 user
> catalogs (and they can be there for a long time)
> Aside from a RC(04) on the LISTCAT CAT(), there seems to be no other issue.
> However, I cannot find a way to get rid of those as the dataset name does
> not adhere to restrictions.
> Any ideas?
> jack
>
> --
> 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: S23E abend

[Joe Monk]

Reason code 00 is a storage key mismatch.

Joe

On Wed, Aug 24, 2022 at 3:19 PM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> The "normal" reason this happens (at least to me) is because the task
> isn't authorized to issue the detach.  It has nothing to do with whether or
> not the task was able to start, because the task may not have needed to be
> authorized when it started, but needs it to perform a specific function and
> that function happens to be a detach.  This is almost always because of an
> error in the APF list, or an error that you didn't link the module
> correctly.  Since you said you have not changed anything except that it's a
> DR test, then I have to assume your problem is APF.
>
> It really doesn't cost you anything to check your APF datasets are really
> authorized int he right place, there is a health check that does it for you
> and I think there is even a SDSF screen that allows you to see that
> information now.
>
> Brian
>
> --
> 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: SDSF z/OS 2.5

[Joe Monk]

https://knowledge.broadcom.com/external/article/51114/isf024i-user-acidname-not-authorized-to.html

Joe

On Mon, Aug 22, 2022 at 8:57 AM James, Joseph L. (CTR) <
04326c675d2d-dmarc-requ...@listserv.ua.edu> wrote:

> What is missing here?  Ran SDSF in 2.2, 2.3 and 2.4 with full SAF
> configuration.  No issues in prior releases but getting the following with
> z/OS 2.5 and can't see where the issue is with group assignment.
>
> ISF024I USER xxx  NOT AUTHORIZED TO SDSF, NO GROUP ASSIGNMENT
>
> Stc   SDSF and SDSFAUX up and running looks fine,  no errors STCs look
> the same as the others that are defined in z/OS 2.4 LPAR configurations.
> Migration Guide, Installation and Operation docs has provided a solution as
> to why group assignments aren't being made.  Anyone else experienced this
> issue with assigning groups?
>
> --
> 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: Is JES2 z22 mode required on z/OS 2.5?

[Joe Monk]

Step 4.10.1.1

Starting with z/OS V2R5, JES2 no longer supports the z11 level for
checkpoint data sets. z22 mode was introduced in z/OS V2R2.

https://www.ibm.com/docs/en/zos/2.4.0?topic=SSLTBW_2.4.0/com.ibm.zos.v2r4.e0zm100/Export_zOS_V2R4_to_V2R5_Upgrade_Workflow.html#mark147

Joe

On Thu, Aug 18, 2022 at 6:06 PM IBM user  wrote:

> Hi Mark,
>
> Thanks.  Been down that path. The APAR states that the release doc is
> "explicit" in the need for z22 mode, but in fact it is silent.
>
> Now I look in the 2.5 JES2 Tuning and Initialization Reference, and find
> the answer:
>   COLD_START_MODE = z11 | z22 | DEFAULT
> So, it seems they IBM was thinking of changing z22 mode to a requirement,
> but backed off.
>
> IBM User
>
> - Original message -
> From: Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is JES2 z22 mode required on z/OS 2.5?
> Date: Thursday, August 18, 2022 10:12 AM
>
> Look at this APAR, it should answer your question. Yes, it is.
>
> https://www.ibm.com/support/pages/apar/OA62594
>
> Mark Jacobs
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key -
> https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
>
>
> --- Original Message ---
> On Thursday, August 18th, 2022 at 9:45 AM, IBM user 
> wrote:
>
>
> > Is JES2 z22 checkpoint mode required as pre-req for z/OS 2.5?
> >
> > I see mention of this in Marna Walle's presentations,
> >
> > -- Activate z22 mode -(REQUIRED-IF, as of V2.5)
> >
> > and perhaps it was being considered at one time, but I am unable to
> locate any record of this requirement in the z/OS 2.5 release manuals.
> >
> > Any ideas?
> >
> > --
> > 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: Question about z16 allowed cores

[Joe Monk]

See here: https://www.ibm.com/downloads/cas/6NW3RPQV

* If ordering a zIIP, one or more general purpose processor (CP) per the
specialty engine is required. IBM has modified the ratio of zIIP to CPs to
be 2:1. Up to two zIIP processors may be purchased for every general
purpose processor purchased on the server.
So, if you have a MAX82, and 39 CP, you have have a max of 43 zIIP. But
note the limit in that chart: a MAX82 can have a max of 54 zIIP.

Joe

On Tue, Aug 16, 2022 at 11:44 AM Horne, Jim  wrote:

> Does anyone know if you can have more than 39 total cores configured on a
> z16 sub-capacity model with the MAX82 feature?  I know you can have a max
> of 39 GCPs, but can zIIPs spill over to the second book?  What about ICFs
> and IFLs?
>
> Thanks,
> Jim Horne
> 
> NOTICE: All information in and attached to the e-mails below may be
> proprietary, confidential, privileged and otherwise protected from improper
> or erroneous disclosure. If you are not the sender's intended recipient,
> you are not authorized to intercept, read, print, retain, copy, forward, or
> disseminate this message. If you have erroneously received this
> communication, please notify the sender immediately by phone (704-758-1000)
> or by e-mail and destroy all copies of this message electronic, paper, or
> otherwise. By transmitting documents via this email: Users, Customers,
> Suppliers and Vendors collectively acknowledge and agree the transmittal of
> information via email is voluntary, is offered as a convenience, and is not
> a secured method of communication; Not to transmit any payment information
> E.G. credit card, debit card, checking account, wire transfer information,
> passwords, or sensitive and personal information E.G. Driver's license,
> DOB, social security, or any other information the user wishes to remain
> confidential; To transmit only non-confidential information such as plans,
> pictures and drawings and to assume all risk and liability for and
> indemnify Lowe's from any claims, losses or damages that may arise from the
> transmittal of documents or including non-confidential information in the
> body of an email transmittal. 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: CC compiler under CMS - LSEARCH option

[Joe Monk]

you cant do it that way.

lsearch prepends to the include...

https://www.ibm.com/docs/en/zos/2.1.0?topic=options-lsearch-nolsearch

Joe

On Sat, Aug 13, 2022 at 4:49 PM Binyamin Dissen 
wrote:

> I am trying to tell the C compiler to use MACRO file types for #include.
>
> The doc states:
>
> ===
>  COMMANDS CC All Help Information
> LSEarch(opt)|NOLSEarch NOLSEARCH is the default. The LSEARCH option
> directs the preprocessor to
> look for the user include files in the specified libraries or
> MACLIBs,
> on the specified minidisks, or in the specified BFS directories. The
> format of the LSEARCH option is:LSEARCH (opt,opt,...)
> where:   opt may be one of the following:-  A CMS
> filemode
> -  A BFS path name-  (fname.suffix) = (subopt,subopt,...)
> where:
> - fname is the name of the include file or *   - suffix is the
> suffix of the include file or *   - subopt can be a filemode,
> LIB(maclib_name,maclib_name,...), or NOLIB.
>
> ===
>
> I have tried multiple versions of LSEARCH with no luck.
>
> cc **name** c * (lsearch(*.macro)
> WARNING CCN3261 Suboption *.macro is not valid for option LSEARCH.
>
> cc **name** c * (lsearch(*.*.*)
> WARNING CCN3261 Suboption *.*.* is not valid for option LSEARCH.
>
> I can simply rename the MACRO to H and it works, but this is a bug in my
> bonnet.
>
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
> --
> 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: Blank page print after upgrade Zos2.5

[Joe Monk]

"rather, the separator routine calls IEFSD095."

Which is EXACTLY what I said!

"The JES2 guide says that JES2 calls IEFSD095 to build the separator
pages..."

Joe


On Wed, Aug 10, 2022 at 11:49 AM Seymour J Metz  wrote:

> Read it more carefully. IEFSD095 is not the separator routine, rather, the
> separator routine calls IEFSD095. JES2, JES3, the External Writer and
> packages running over FSS each have their own separator routines.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Joe Monk [joemon...@gmail.com]
> Sent: Wednesday, August 10, 2022 11:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Blank page print after upgrade Zos2.5
>
> The JES2 guide says that JES2 calls IEFSD095 to build the separator
> pages...
>
> "For printer-destined output, the separator routine can use an IBM-supplied
> routine to construct separation records in a block character format. This
> routine is a reentrant module named IEFSD095 that resides in the module
> library SYS1.AOSB0."
>
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.5.0%3Ftopic%3Dworks-using-block-character-routine&data=05%7C01%7Csmetz3%40gmu.edu%7Ca899369179cd4df3091408da7ae3159c%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637957412985403974%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3k%2FZqpxczUZUPp5QegQNgG%2FaQV6i4sgdx3nqQoXvR7I%3D&reserved=0
>
> Joe
>
> On Wed, Aug 10, 2022 at 10:01 AM Seymour J Metz  wrote:
>
> > IEFSD095 is not a JES routine; it's part of the External Writer. JES2 and
> > JES3 have their own separator routines, either of which may be replaced
> by
> > an installation-specific separator.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> > of Allan Staller [0387911dea17-dmarc-requ...@listserv.ua.edu]
> > Sent: Wednesday, August 10, 2022 8:09 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Blank page print after upgrade Zos2.5
> >
> > Classification: Confidential
> >
> > JES Seperator Page exit? (IEFSD095?)
> > Check the fine manuals.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Tommy Tsui
> > Sent: Tuesday, August 9, 2022 7:04 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Blank page print after upgrade Zos2.5
> >
> > [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 found most statements printing a blank page after separator exit.
> > Anyone hits the same problem after upgrade to zos2.5. We check all the
> jes2
> > spool data are normal without error. Thanks
> >
> > --
> > 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.
> > 
> >
> > -

Re: Blank page print after upgrade Zos2.5

[Joe Monk]

The JES2 guide says that JES2 calls IEFSD095 to build the separator pages...

"For printer-destined output, the separator routine can use an IBM-supplied
routine to construct separation records in a block character format. This
routine is a reentrant module named IEFSD095 that resides in the module
library SYS1.AOSB0."

https://www.ibm.com/docs/en/zos/2.5.0?topic=works-using-block-character-routine

Joe

On Wed, Aug 10, 2022 at 10:01 AM Seymour J Metz  wrote:

> IEFSD095 is not a JES routine; it's part of the External Writer. JES2 and
> JES3 have their own separator routines, either of which may be replaced by
> an installation-specific separator.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Allan Staller [0387911dea17-dmarc-requ...@listserv.ua.edu]
> Sent: Wednesday, August 10, 2022 8:09 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Blank page print after upgrade Zos2.5
>
> Classification: Confidential
>
> JES Seperator Page exit? (IEFSD095?)
> Check the fine manuals.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Tommy Tsui
> Sent: Tuesday, August 9, 2022 7:04 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Blank page print after upgrade Zos2.5
>
> [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 found most statements printing a blank page after separator exit.
> Anyone hits the same problem after upgrade to zos2.5. We check all the jes2
> spool data are normal without error. Thanks
>
> --
> 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
>
> --
> 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: Extending a VTOC

[Joe Monk]

The Extend VTOC is nice, but has one problem ... you could end up with your
VTOC in multiple extents.

I would back it up, empty the volume, and reinit.

Joe

On Mon, Aug 1, 2022 at 10:01 AM Jack Zukt  wrote:

> Thank you all for your input.
> I am going to try it like that
> Regards,
> Jack
>
> On Mon, 1 Aug 2022 at 11:58, Immo  wrote:
>
> > P.S.
> > EXTVTOC(n) is a parameter of the ICKDSF command REFORMAT.
> > Michael
> >
> > -Ursprüngliche Nachricht-
> > Von: IBM Mainframe Discussion List  Im Auftrag
> > von Jack Zukt
> > Gesendet: Montag, 1. August 2022 12:15
> > An: IBM-MAIN@LISTSERV.UA.EDU
> > Betreff: Extending a VTOC
> >
> > Hi all,
> > It has been way too many years since the last time I dabbled with ICKDSF
> > and VTOC definitions (probably over twenty, but I would rather not do the
> > math).
> > Back on those days, if memory serves me right, the only way to extend a
> > VTOC was to clean the DASD of all its contents, put it offline, and
> > recreate the VTOC with the new size. As a few years have passed, I have
> > been going through the ICKDSF manual trying to find out if a VTOC can be
> > extended without having to clear the volume first. I can not say that I
> > have became enlightened. It seems to be possible but I am not quite sure
> > about it. And this being a production volume I really would hate if
> things
> > do not work as expected.
> > So, in a nut shell, can I extend a VTOC from 90 to 900 tracks without
> > having first to clean the DASD of all its files?
> > Thank you in advance for any help,
> > Best regards
> > Jack
> >
> > --
> > 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: AWS and IDRC/compression

[Joe Monk]

I dont even understand what the problem is.

AWS is simply a disk format for a sequential file of tape blocks. What is
inside those blocks are for the program that reads/writes them to decide...
AWS does not decide that. You can easily compress, slice into blocks, and
write to AWS.

Sam Golobs article on AWSTAPE makes that pretty clear ...
https://www.cbttape.org/awstape.htm

Joe

On Mon, Aug 1, 2022 at 7:59 AM Seymour J Metz  wrote:

> Why is IDRC compatibility an issue when you're not using a physical
> cartridge or physical drive that supports IDRC? If you modify AWS to
> support compression, use whatever format that gives you the best results.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Tony Thigpen [t...@vse2pdf.com]
> Sent: Saturday, July 30, 2022 12:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: AWS and IDRC/compression
>
> I am working with my VTA vendor to reduce storage usage on the
> appliance. Currently, they can compress after the unmount and uncompress
> before the mount. But, this takes time, especially when servicing the
> mount request if the tape is large.
>
> I was thinking that doing an IDRC implementation, which is stream based
> and performed during write/read, it might be faster even if it's not
> compresses as much as with their current method.
>
> But, if the AWS file is not compatible with IBM's implementation, then
> it's going to add a step to send them the file. The current compressed
> files can be uncompressed using standard linux tools.
>
> Tony Thigpen
>
> Jay Maynard wrote on 7/29/22 22:44:
> > I'm curious. What are you trying to accomplish with it? If it's just a
> > matter of faster transmission of entire tape images, AWS tapes compress
> > very well.
> >
> > On Fri, Jul 29, 2022 at 8:38 PM Tony Thigpen  wrote:
> >
> >> Yes. But, it sounds like nobody else will support it as a data
> >> interchange, so it may be unusable for us.
> >>
> >> I will go look at it.
> >>
> >> Tony Thigpen
> >>
> >> Jay Maynard wrote on 7/29/22 06:38:
> >>> Are you talking about the tape data being compressed inside the AWS
> >> image?
> >>> Hercules has a format that does this, upwardly compatible with AWS,
> >> called
> >>> HET (Hercules Emulated Tape), but I don't know of any other
> >> implementations
> >>> of it. Each block is compressed after being received from the program
> >>> writing the tape but before being written to the file and uncompressed
> >>> after being read but before being returned to the program reading the
> >> tape.
> >>>
> >>> On Fri, Jul 29, 2022 at 3:56 AM Tony Thigpen  wrote:
> >>>
>  Does anyone know of any 'standard' for stream based (during file
>  creation) compression of AWS tapes?
> 
>  Tony Thigpen
> 
>  --
>  For IBM-MAIN subscribe / signoff / archive access instructions,
>  send email to lists...@listserv.ua.edu with the message: INFO
> IBM-MAIN
> 
> >>>
> >>>
> >>> --
> >>> Jay Maynard
> >>>
> >>> --
> >>> 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
> >>
> >
> >
> > --
> > Jay Maynard
> >
> > --
> > 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: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name IDENTIFY

[Joe Monk]

Moreover, a CICS macro would start with DFH... it wouldnt be called
IDENTIFY.

Joe

On Wed, Jul 20, 2022 at 8:41 AM Ward Able, Grant  wrote:

> As stated by IBM Hursley (John Tilling) on the CICS-List,  CICS does not
> ship an IDENTIFY macro!
>
> Regards - Grant.
> Telephone Internal: 201496 (London)
>
> EAM - Enterprise Application Middleware
>
> In theory, there's no difference between theory and practice. In practice,
> there is.
>
> Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are. - John Wooden
>
> If you don't have time to do it right, when will you have the time to do
> it over? - John Wooden
>
>
>
> DTCC Public (White)
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Seymour J Metz
> Sent: 20 July 2022 14:18
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS
> macro name IDENTIFY
>
> ATTENTION: External Email - Be Suspicious of Attachments, Links and
> Requests for Login Information.
>
> IDENTIFY has existed and been documented since Old Man Noach got high on
> PCP. Yes, CICS should have known better.
>
> The RFE wouldn't be for unique names; that ship has sailed. It would be
> for new syntax on COPY.
>
> If your program needs both, you're screwed. Welcome to CM Hell.
>
>
> --
> Shmuel (Seymour J.) Metz
>
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3&data=05%7C01%7Cgwardable%40DTCC.COM%7C84a10466544949519ea508da6a5254cd%7C0465519d7f554d47998b55e2a86f04a8%7C0%7C0%7C637939199102819262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RmTDzrKLqfpMeWzgN3LzujQbqe9CNNgHDschdGnwYwY%3D&reserved=0
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
> Sent: Wednesday, July 20, 2022 9:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS
> macro name IDENTIFY
>
> On Wed, 20 Jul 2022 12:18:56 +, Seymour J Metz wrote:
>
> >There is no COPY ddname(member) in HLASM. That sounds like an obvious
> candidate for an RFE.
> >
> Hasn't the MVS macro name IDENTIFY existed long enough that CICS should
> have known better?
>
> That's not an RFE; tt's a bug; BAD.  Suppose a program needs both services.
>
>
> >-Original Message-
> >From: Farley, Peter x23353
> >Sent: Tuesday, July 19, 2022 2:07 PM
> >
> >Cross-posted to IBM-MAIN and CICS-L.
> >
> >We just encountered this.  Our SDLC mechanism has CICS.BASE.MACLIB (an
> >ALIAS for the current product version library) positioned in the
> >assembler translate step BEFORE the SYS1.MACLIB library.  SOP, put all
> >licensed product libraries ahead of base system libraries, right?
> >
> >Not in this case.  Turns out we have some old assembler ode that uses
> >the MVS IDENTIFY macro for reasonable business purposes, but now the
> >CICS MACLIB ALSO has a macro named IDENTIFY.
>
> --
> 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
> DTCC DISCLAIMER: This email and any files transmitted with it are
> confidential and intended solely for the use of the individual or entity to
> whom they are addressed. If you have received this email in error, please
> notify us immediately and delete the email and any attachments from your
> system. The recipient should check this email and any attachments for the
> presence of viruses. The company accepts no liability for any damage caused
> by any virus transmitted by this email. Message content created by DTCC is
> automatically secured using Transport Layer Security (TLS) encryption and
> will be encrypted and sent through a secure transmission connection if the
> recipient's system is configured to support TLS on the incoming email
> gateway. If there is no TLS configured or the encryption certificate is
> invalid on the recipient's system, the email communication will be sent
> through an unencrypted channel. Organizations communicating with DTCC
> should be using TLS v1.2 or newer to ensure continuation of encrypted
> communications. DTCC will not be responsible for any disclosure of private
> information or any related security incident resulting from an
> organization's inability to receive secure electronic communications
> through the current version of TLS.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instr

Re: z/OS 1.4 submit

[Joe Monk]

FTP a job to jes2?

Joe

On Thu, Jul 14, 2022 at 11:01 AM rpinion865 <
042a019916dd-dmarc-requ...@listserv.ua.edu> wrote:

> I'm working on an old z/OS 1.4 system. We need the ability to submit a
> batch job from within OMVS. But, the submit command isn't there. Is there
> any other way to submit a batch job from within OMVS?
>
> Sent with [Proton Mail](https://proton.me/) secure email.
>
> --
> 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: [EXTERNAL] FedEx to move entirely to the cloud

[Joe Monk]

>From 1995...

https://books.google.com/books?id=L_AXQqZphvYC&pg=PP93&lpg=PP93&dq=fedex+cannot+get+off+the+mainframe&source=bl&ots=RJK8q0mlHc&sig=ACfU3U1Go2Rt2LmKmmx6rjISivUeRxhZpg&hl=en&sa=X&ved=2ahUKEwi-ko6oser4AhX9KkQIHVutDp8Q6AF6BAgsEAM#v=onepage&q=fedex%20cannot%20get%20off%20the%20mainframe&f=false

Joe

On Fri, Jul 8, 2022 at 5:38 PM Ed Jaffe  wrote:

> On 7/8/2022 2:53 PM, Dave Barry wrote:
> > No surprise.  FedEx announce years ago that they were getting off the
> mainframe "next year."
>
> Can't tell you how many folks I've met in the 11th year of their
> company's 3-year conversion off the mainframe...
>
>
> --
> 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
>

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

Re: Converting assembler to COBOL help

[Joe Monk]

Why in the heck would you want to do that?

Joe

On Fri, Jul 8, 2022 at 5:32 PM Tom Ross  wrote:

> Greetings mainframers!
>
> This has porobbaly been asked and answered, but are there tools or
> companies
> that can convert or help to rewrite assembler applications or just programs
> into COBOL?  Any suggestions?
>
>
> Cheers,
> TomR  >> COBOL is the Language of the Future! <<
> AKA:  Captain COBOL, Tom Ross
>
> --
> 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: is there any documentation on using the new 64 bit instructions?

[Joe Monk]

Hello...

The link says:

"All AMODE 31 programs that are involved in the interoperability scenario
need to be non-XPLINK. All AMODE 31 and AMODE 64 programs that are involved
in the interoperability scenario need to be reentrant."

Joe

On Tue, Jun 28, 2022 at 2:59 PM Denis <
01664d8ede6c-dmarc-requ...@listserv.ua.edu> wrote:

> Hi Joe,
> you should have a look at LE 31/64 bit interoperability:
>
> https://www.ibm.com/docs/en/zos/2.4.0?topic=interoperability-introduction-amode-31-amode-64-programs
> Denis.
>
> -----Original Message-
> From: Joe Monk 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Tue, Jun 28, 2022 7:33 pm
> Subject: Re: is there any documentation on using the new 64 bit
> instructions?
>
> If youre using LE, you can't mix 31 and 64 bit, because 64-bit C using LE
> uses a 64-bit XPLINK which passes parameters from the stack above the bar.
>
> I think you will have to write a glue assembler module to receive control
> in AMODE 64 then SAM31 CALL  SAM64 and back.
>
> Joe
>
>
>
> On Tue, Jun 28, 2022 at 9:13 AM Colin Paice  wrote:
>
> > I've been working on calling an (amode 31) assembler program from a 64
> bit
> > C program, and have been struggling.Is there is a good guide on how to
> use
> > these new instructions?
> > For example
> > 1)
> > I've found you need to use a  LLGTR R1... instruction to clear the
> register
> > before using a L R1... because without it the high part of the register
> > will have some 64 bit rubbish in it
> >
> > 2)
> > I used
> >
> > BAKR  R14,0
> > PR
> > But it kept returning in amode 24 bit mode.  It needs BSM  14,0  before
> > the  BAKR.__
> >
> > The POP tells you all about the instructions - but not how to use it.
> The
> > z/OS doc says use BACK/PR  without mentioning the  BSM, so this is not
> > completely trustworthy.
> > _
> > Is there a better place to ask?
> >
> > Colin
> >
> > --
> > 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: is there any documentation on using the new 64 bit instructions?

[Joe Monk]

If youre using LE, you can't mix 31 and 64 bit, because 64-bit C using LE
uses a 64-bit XPLINK which passes parameters from the stack above the bar.

I think you will have to write a glue assembler module to receive control
in AMODE 64 then SAM31 CALL  SAM64 and back.

Joe



On Tue, Jun 28, 2022 at 9:13 AM Colin Paice  wrote:

> I've been working on calling an (amode 31) assembler program from a 64 bit
> C program, and have been struggling.Is there is a good guide on how to use
> these new instructions?
> For example
> 1)
> I've found you need to use a  LLGTR R1... instruction to clear the register
> before using a L R1... because without it the high part of the register
> will have some 64 bit rubbish in it
>
> 2)
> I used
>
> BAKR  R14,0
> PR
> But it kept returning in amode 24 bit mode.  It needs BSM   14,0  before
> the  BAKR.__
>
> The POP tells you all about the instructions - but not how to use it.  The
> z/OS doc says use BACK/PR  without mentioning the  BSM, so this is not
> completely trustworthy.
> _
> Is there a better place to ask?
>
> Colin
>
> --
> 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: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Joe Monk]

aka Marketechture.

Joe

On Mon, Jun 20, 2022 at 8:45 AM David Crayford  wrote:

> Isn’t buzzword a buzzword? There’s some irony there.
>
> > On 20 Jun 2022, at 9:38 pm, Gerhard Adam  wrote:
> >
> > discussed as to be non-existent.   This sounds like more marketing hype
> perpetrated
>
> --
> 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: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Joe Monk]

https://ntrs.nasa.gov/citations/1969381

Joe

On Mon, Jun 20, 2022 at 7:00 AM David Crayford  wrote:

> And yet still nobody seems to have grokked the fundamental differences
> between online systems and event-driven architectures. This is obviously
> not the forum for discussions on contemporary software architectures. It
> always deteriorates into a deluge of boring and undiscerningposts about
> how it's nothing new and was already done back in the day on a S360 with
> 4K ram and a paper-taper reader held together with gaffer tape.
>
> https://en.wikipedia.org/wiki/Event-driven_architecture
>
> On 20/06/2022 7:40 pm, Seymour J Metz wrote:
> > Before MQ there were QTAM and TCAM.
> 
> >
> > There have been mainframes running real time applications since the
> 1960s. Air traffic control. Airline reservations. Controlling traffic
> lights (UNIVAC, not IBM.) These may not be the best examples, but they were
> the first to come to mind, and used off the shelf mainframes.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of René Jansen [rene.vincent.jan...@gmail.com]
> > Sent: Monday, June 20, 2022 5:50 AM
> > To:IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM
> and AWS
> >
> > You can make that 'about 30 years ago' - time flies while we’re having
> fun.
> >
> > René.
> >
> >> On 20 Jun 2022, at 09:51, Colin Paice  wrote:
> >>
> >> MQ from IBM developed about 20+ years ago helped get from Batch to real
> >> time.   You put messages to a queue, and it can run IMS transactions
> >> (including OTMA),  CICS transactions, or even batch!.  You can put on
> one
> >> member in a sysplex and get in another member.
> >> It has single put, and also publish/subscribe capability.
> >>
> >> Colin
> >>
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email tolists...@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: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Joe Monk]

CVS is 24/7 some pharmacies. Especially here in Texas.

https://www.cvs.com/store-locator/cvs-pharmacy-locations/24-hour-pharmacies/Texas/Houston

Joe



On Mon, Jun 20, 2022 at 5:52 AM Seymour J Metz  wrote:

> Perhaps some are: CVS isn't.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Bill Johnson [0047540adefe-dmarc-requ...@listserv.ua.edu]
> Sent: Sunday, June 19, 2022 4:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM
> and AWS
>
> Most mainframes store transactions and process in batch? Are you the same
> guy who didn’t know pharmacies are open 24 by 7?
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Sunday, June 19, 2022, 2:03 PM, David Crayford 
> wrote:
>
> On 20/06/2022 12:38 am, Seymour J Metz wrote:
> > Keep in mind that the mainframe can only do batch processing, with input
> from cards. It doesn't support anything like CICS, IMS or Sabre..
>
> What have transactional systems like CICS or IMS got to do with
> real-time, straight-through processing? Most mainframe transactions
> store data that is later processed by batch, typically overnight. In the
> case of banking transactions that require inter-bank settlements this
> can cause delays of several days. In Australia the government mandated
> the NPP (New Payments Platform) which facilities instant payments using
> payids, which can be an email address, cellphone numbers etc. The API is
> a simple REST API using HTTP
>
> https://secure-web.cisco.com/1cVCppuTlJ_nNLCyIpfi-pFWBClb6lq0nQl_7E--OgnADnbuDkYX8bcjtN6oIQ16B7sRfQ6OOuKQq5QEsgUNf1wFNw-vDdy4M0iIKKAuBN963Nz6gCY1jLEhKQkGKEoyGO9Z-wZYLbalLh_6t-yXF0tJt57oapuTFDOrG3GFsopnPGoLuZ4lhsE-QLh8nA4FrboD8IlzLKjbPsQj-pX4nCx-5TqIo8psGz3mESLroERbYAiILA7fDZwB43yTbn-VzeobnA6ekc_rpFTqhR0IQ5Sh4Edlu7N1EUQ58yn28hGb_a0yq75xJMnQiCxA0sU1Si67g84Rll_yCyt27ggj4mSC-Y501bGnMLip29-0IurTidywtHtLuc7WbjeLeon2CRuFO9mcnFZ5ZFvA_KT8equXAEbZ7tPu1HS-0BD6cCWjPwQggcoAS7FwZRvM34g_d/https%3A%2F%2Fnppa.com.au%2Fwp-content%2Fuploads%2F2020%2F10%2FNPP-API-Framework-v4.0-Final.pdf
> .
> It's my understanding that no bank implemented NPP on the mainframe.
>  From the presentations I've seen they used CDC to capture writes and
> then published events to Kafka, which was fanned out to different
> micro-services to do fraud detection, payments, push notifications etc.
> Back in the day straight-through processing was a pipe dream which is
> why we have overnight batch. It's a relic of applications written
> decades ago for very different hardware platforms.
>
>
> > It's much better to run Linux than to get an IFL, which can only run
> batch.
>
> I have no idea what you mean?
>
> >
> > Cynical? Moi?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of David Crayford [dcrayf...@gmail.com]
> > Sent: Sunday, June 19, 2022 2:36 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM
> and AWS
> >
> > On 19/06/2022 5:23 am, Enzo D'Amato wrote:
> >> I also agree, but as a non-insider, I wanted to know what others were
> thinking. I also belive that in most cases, the effort spent trying to get
> off the mainframe would be better spent actually fixing the code running on
> it in the first place. Moving around broken code doesn't automatically fix
> it.
> > It's not just about fixing broken code. If you read the ING CIO's
> > remarks about why they wanted off the mainframe it's not about the
> > platform. Nobody denies that mainframes are insanely brilliant hardware
> > platforms. ING wanted to get rid of batch and move towards an event
> > driven architecture using pub/sub where they can easily deploy loosely
> > coupled micro-services to provide cutting edge products. The technology
> > stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
> > Avro etc.  The retail banking industry has been disrupted by fintechs so
> > waiting for an overnight batch schedule for settlements is a competitive
> > disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch
> > applications is a VERY heavy lift.
> >
> >
> https://secure-web.cisco.com/1GoiNO6FBPSWW0D9FZYVYixer1jsPeSd_xH-wmi6jMOC-onAkZQ4Pkf3c1UMGWbQeEprnkSWa1xGxz4vvn-LF0jVrCFlVVFZKQJ4Jti8nbQ7QchsOxhwNiwluJrdKkQP2nXXHQH2Ut2NNa9VChfVBIDR7Akw4ud6_pIXLAFXO5l73Sv-iLZFNU1MWWnLapWhhCKvytdzs7EJTvNZ2qbU8xwCdBEl1UkUuL-jHHZLk6xJPxAadVRWP1nuLz8i5AZrfvDI8u8rZ0V0DT77_Uvu8klHLbL9xe2qaYi1P6a6mc8r9Aj2jothGC-CR9cbCgb-JVXupgin9UctH5C_iVMyn_T-9jzZjtNyZDETxb8hXMU-BOuUz89MGu1nniZJ2tvSSN8yh5A6K-_It8fA10UFCfSBhOB0NVkwKL5M8A2BxZ9_e111GnxGK_PAbj0wh5fvU/https%3A%2F%2Fwww.theregister.com%2F2016%2F07%2F01%2Fing_mainframe_strategy%2F
> <- read
> > the comments section. It's hilarious :)
> >

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Joe Monk]

"Please elaborate how IMS TM is anything more than a message queue that
processes transactions."

Youre quibbling about form over substance.

As an example, NASA uses message queue processing for spacecraft telemetry.

Joe



On Sun, Jun 19, 2022 at 4:39 PM David Crayford  wrote:

> On 20/06/2022 5:27 am, Joe Monk wrote:
> > "What have transactional systems like CICS or IMS got to do with
> > real-time, straight-through processing? Most mainframe transactions
> > store data that is later processed by batch, typically overnight."
> >
> > If you think CICS and IMS are transactional only, youre stuck in the
> '80s.
>
> I've spent the last 20+ years working on ISV products for IMS and CICS.
> Please elaborate how IMS TM is anything more than a message queue that
> processes
> transactions. If you want to throw IMS Connect into the mix then please
> comment as I have in depth knowledge of the architecture as I was on dev
> on the
> IMS Connect Extensions product.
>
> > As an example, ICCF on VSE uses CICS as the TP Monitor. Tell me that
> > writing code, storing it in a library, compiling, etc. are not
> "real-time".
> Awesome :/
>
> --
> 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: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Joe Monk]

"What have transactional systems like CICS or IMS got to do with
real-time, straight-through processing? Most mainframe transactions
store data that is later processed by batch, typically overnight."

If you think CICS and IMS are transactional only, youre stuck in the '80s.
As an example, ICCF on VSE uses CICS as the TP Monitor. Tell me that
writing code, storing it in a library, compiling, etc. are not "real-time".

Joe

On Sun, Jun 19, 2022 at 1:03 PM David Crayford  wrote:

> On 20/06/2022 12:38 am, Seymour J Metz wrote:
> > Keep in mind that the mainframe can only do batch processing, with input
> from cards. It doesn't support anything like CICS, IMS or Sabre..
>
> What have transactional systems like CICS or IMS got to do with
> real-time, straight-through processing? Most mainframe transactions
> store data that is later processed by batch, typically overnight. In the
> case of banking transactions that require inter-bank settlements this
> can cause delays of several days. In Australia the government mandated
> the NPP (New Payments Platform) which facilities instant payments using
> payids, which can be an email address, cellphone numbers etc. The API is
> a simple REST API using HTTP
>
> https://nppa.com.au/wp-content/uploads/2020/10/NPP-API-Framework-v4.0-Final.pdf.
>
> It's my understanding that no bank implemented NPP on the mainframe.
>  From the presentations I've seen they used CDC to capture writes and
> then published events to Kafka, which was fanned out to different
> micro-services to do fraud detection, payments, push notifications etc.
> Back in the day straight-through processing was a pipe dream which is
> why we have overnight batch. It's a relic of applications written
> decades ago for very different hardware platforms.
>
>
> > It's much better to run Linux than to get an IFL, which can only run
> batch.
>
> I have no idea what you mean?
>
> >
> > Cynical? Moi?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of David Crayford [dcrayf...@gmail.com]
> > Sent: Sunday, June 19, 2022 2:36 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM
> and AWS
> >
> > On 19/06/2022 5:23 am, Enzo D'Amato wrote:
> >> I also agree, but as a non-insider, I wanted to know what others were
> thinking. I also belive that in most cases, the effort spent trying to get
> off the mainframe would be better spent actually fixing the code running on
> it in the first place. Moving around broken code doesn't automatically fix
> it.
> > It's not just about fixing broken code. If you read the ING CIO's
> > remarks about why they wanted off the mainframe it's not about the
> > platform. Nobody denies that mainframes are insanely brilliant hardware
> > platforms. ING wanted to get rid of batch and move towards an event
> > driven architecture using pub/sub where they can easily deploy loosely
> > coupled micro-services to provide cutting edge products. The technology
> > stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
> > Avro etc.  The retail banking industry has been disrupted by fintechs so
> > waiting for an overnight batch schedule for settlements is a competitive
> > disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch
> > applications is a VERY heavy lift.
> >
> >
> https://secure-web.cisco.com/1GoiNO6FBPSWW0D9FZYVYixer1jsPeSd_xH-wmi6jMOC-onAkZQ4Pkf3c1UMGWbQeEprnkSWa1xGxz4vvn-LF0jVrCFlVVFZKQJ4Jti8nbQ7QchsOxhwNiwluJrdKkQP2nXXHQH2Ut2NNa9VChfVBIDR7Akw4ud6_pIXLAFXO5l73Sv-iLZFNU1MWWnLapWhhCKvytdzs7EJTvNZ2qbU8xwCdBEl1UkUuL-jHHZLk6xJPxAadVRWP1nuLz8i5AZrfvDI8u8rZ0V0DT77_Uvu8klHLbL9xe2qaYi1P6a6mc8r9Aj2jothGC-CR9cbCgb-JVXupgin9UctH5C_iVMyn_T-9jzZjtNyZDETxb8hXMU-BOuUz89MGu1nniZJ2tvSSN8yh5A6K-_It8fA10UFCfSBhOB0NVkwKL5M8A2BxZ9_e111GnxGK_PAbj0wh5fvU/https%3A%2F%2Fwww.theregister.com%2F2016%2F07%2F01%2Fing_mainframe_strategy%2F
> <- read
> > the comments section. It's hilarious :)
> >
> > The doubly whammy is there's a skills crisis slowly unraveling. In the
> > last year we've had 3 key resources move to 3 day weeks with a view to
> > retiring. Replacing highly skilled assembler programmers with deep
> > subsystem knowledge is proving to be difficult. Young people don't want
> > to learn HLASM as they consider it a dead-end. Their position is "why
> > invest 3-4 years learning a language that is useless if you move to
> > another industry?" I can't comment about COBOL application developers.
> >
> > In 10 years time I expect the mainframe to be alive and kicking and
> > significantly modernized. The small/medium shops will probably be all
> > gone. When I first moved to my current town in 1998 there were 25-30
> > mainframe sites. Now there are 3 and 1 is on life support. One of our
> > customers re-platformed their CICS/COBOL/Batch applications from a z9 to
> > 

Re: data set deletion problem

[Joe Monk]

Radoslaw,


It's not good to argue with the guy who writes z/OS for ibm how it works.

Joe

On Mon, Jun 6, 2022, 06:50 Radoslaw Skorupka  wrote:

> > On Tue, 31 May 2022 13:00:58 +, Peter Relson 
> wrote:
> >
> >> As far as I know, XCFAS would not allocate any data set other than what
> XCF itself needs (perhaps some sort of couple data set)
>
> IMHO XCF is used to allocated LNKLST datasets and I believe it is not
> because XCF needs them.
> And there is a way to unallocate LNKLST datasets in order to perform
> some tasks.
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> 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: How to force use of a single unix process to all bpxbatch calls?

[Joe Monk]

Itschak,

Looks like you want _BPX_SHAREAS=YES.

But note:

"If the extended attribute for the shared address space is not set, the
program will not run in a shared address space, regardless of the setting
of _BPX_SHAREAS. The attribute is set by extattr +s and reset by extattr -s.
If the attribute is set, _BPX_SHAREAS has precedence."

Joe

On Mon, May 30, 2022 at 7:53 AM Itschak Mugzach <
0305158ad67d-dmarc-requ...@listserv.ua.edu> wrote:

> Kirk,
>
> A rexx exec is processing a file system. First call to bpxbatch perform ls
> looping on the directories listed in the root to look for specific files
> (ignore the logix, it was dictated by a uniprocessor and a mixture of
> software).
> I noticed that every call to unix creates (or starts) a shadow STC to
> process the command. My assumption is that the way it works affects elapse,
> and maybe, cpu consumption. I want the program to be as efficient as
> possible.
>
> so, to summarize:
>
>- The Program is a (tso) rexx running unix commands.
>- Using the default shell of the user.
>- I want to eliminate the STC, or keep it for the life of the exec.
>- The quoted statement relates to the fact that I assume it is less
>effective to run unix outside of the address space.
>
> ITschak
>
>
> *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
> Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
> and IBM I **|  *
>
> *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
> *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*
>
>
>
>
>
> On Mon, May 30, 2022 at 3:41 PM Kirk Wolf  wrote:
>
> > I would need more information:
> >
> > - By "the command" do you mean a z/OS Unix shell command?
> >
> > - Why exactly do you want BPXBATCH?
> >
> > - Do you want another STC for each "command", or is that what you don't
> > want?
> >
> > - Do you need the z/OS Unix shell itself, or is it OK to run the command
> > without a shell?
> >
> > - What language is your program developed in?
> >
> > - I don't understand this:
> > "I want to use the same time used to create a new stc every call and that
> > the unix task will remain active the entire job life"
> >
> > Kirk Wolf
> > Dovetailed Technologies
> >
> > On Sun, May 29, 2022, at 8:00 AM, ITschak Mugzach wrote:
> > > I am running a program that calls BPXBATCH several times. Each call
> > creates
> > > another task (STC) that runs the command. I want to use the same time
> > used
> > > to create a new stc every call and that the unix task will remain
> active
> > > the entire job life. Is this possible?
> > >
> > > ITschak
> > >
> > > ITschak Mugzach
> > > *|** IronSphere Platform* *|* *Information Security Continuous
> Monitoring
> > > for z/OS, x/Linux & IBM I **| z/VM coming soon  *
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> > Kirk Wolf
> > Dovetailed Technologies
> > http://dovetail.com
> >
> > --
> > 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