Re: Assembler :- PC Instruction

[Anne & Lynn Wheeler]

apoorva.kanm...@gmail.com (SUBSCRIBE IBM-MAIN Anonymous) writes:
> I have a question on PC instruction for which I have been looking for
> an answer for quite sometime now. According to "Priciples of
> operations" manual, execution of an SVC instruction causes a new PSW
> to be loaded from x'1C0' (SVC FLIH), and program interruption causes a
> new PSW loaded from x'1D0' (Program Interruption FLIH). Now my
> question is what happens when a "PC" instruction is executed. Does a
> new PSW gets loaded from a pre-determined location (like SVC/program
> interrruption) or it's all handled through some micro code?

The problem started with move from OS/VS2 SVS (and single address space)
to OS/VS2 MVS and multiple address spaces (each application) ... however
OS/360 heritage was heavily pointer passing APIs ... as a result an
8mbyte image of the MVS kernel had to appear in every application
16mbyte virtual address space ... so that kernel could access storage
pointed to be the past pointers. the issue was then all the subsystems
were put in each of their own address spaces and when application passed
pointer to subsystem ... the subsystem was running in different address
space than the address space that the parameter pointed to (by the
passed pointer).

The solution was the common segment area, a one megabyte area in every
application 16mbyte address space ... where applications could obtain
parameter space so the pointer to the parameter list passed to subsystem
was identical address in both the application and the subsystem.
However, the requirement for common segment area space was somewhat
proportional to number of concurrent applications and number of
subsystems ... which quickl exceeded one (mbyte) segement ...  and the
common segment area (CSA) morphed into the common system area (CSA).  As
systems continued to grow, the CSA requirement got larger and larger,
4mbytes (kernel+csa is 12mbytes, leaving only 4mbytes for applications,
then 6mbytes in 3033 time-frame (kernel+csa 14mbytes, leaving only
2mbytes for applications) and threatening to become 8mbytes ... leaving
zero bytes for applications.

in the wake of the FS faulure (FS was going to be completely different
than 370, and 370 efforts were being shutdown during FS period, also
lack of 370 offerings during FS period is credited with giving clone
mainframe vendors market foothold), there was mad rush to get stuff back
into 370 product pipeline ... 303x and 3081 Q efforts were kicked off
in parallel. 3081 included 370/xa, 31bit addressing and "access
registers" (subsystems had their own virtual address space, but could
use "access registers" to access "parameter" storage in application
address space). All this was known informally as "811" for the Nov1978
publication date of the architecture specification documents.

In part because of the increasing threat of CSA increasing to 8mbytes
for larger 3033 customers, a subset of "access registers" was
retrofitted to 3033 as "dual-address space" mode ... subsystems could
have their own address space, but also a 2nd address space to access
calling application parameters directly ... w/o needing CSA space.

In 370 (3033) dual-address space mode ... there still wasn't program
call, but a supervisor call which in software would move the application
space address space to secondary and then load the subsystem address
space and enter the called subsystem. In 370/xa and "access register"
program call had a system defined table with all the necessary
information to do that function directly as part of the program call
instruction (whether implemented in hardware, microcode, picocode and/or
some combination)

Z/archiecture principles of opration references system defined ETEs
(entry-table entrys) for program call instruction which includes a
number options, including switching address spaces or not switching
address spaces, changing instruction address, etc.

"Interrupts" save the current PSW and load a new (static) PSW.

Each Program Call ETE has controls for PSW fields that are saved and how
much of new fields (unique to each ETE) are loaded ... as well as any
address space games that might be played ... and various other rules
(description goes on for more than dozen pages).

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

SMF:- IEFU83, IEFU84 exits

[SUBSCRIBE IBM-MAIN Anonymous]

My assumption is that SMF performs some house-keeping functions before passing 
control over to IEFU83/IEFU84 exits. The minimum house-keeping functions that I 
could think of are   a. Establish an ESTAE recovery routine (may be FRR for 
IEFU84??)   b. GETMAIN to obtain SAVEAREA for the exits (Please let me know if 
there are any more functions that SMF could perform). 

Now my question is does SMF perform these house-keeping functions only once, 
and uses the same recovery routine stack/SAVEAREA for all the different U83/U84 
exits defined on the system OR it performs these house-keeping functions each 
time a different U83/U84 exit is to be called?

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

Re: vendor distributes their private key

[Andrew Rowley]

On 29/08/2019 9:18 am, Charles Mills wrote:


But for certificate-based client authentication, the server admin must send the 
client admin a client certificate AND its private key. Why? Philosophically, 
because a client certificate signed by a trusted CA does not prove the 
authenticity of the client. A man-in-the-middle might have previously 
intercepted the certificate and now be sending it out from HIS client as its 
own.


This doesn't sound right somehow. I suspect it is often implemented that 
way, but it sounds worse than password authentication with a good password.


With a password:
- the server admin supplies a password
- you are forced to change the password, the server admin should not 
know the new password
- It's considered bad if the server admin can e.g. run a cracking tool 
to find out your password


With the certificate based client authentication as described
- The server admin has your credentials
- you can't change them?

My understanding of the way client authentication is supposed to work

- The client generates a public/private key pair
- The public key is incorporated into a certificate, signed by a CA. In 
this case it is quite valid for the server admin to be the CA. At this 
point the CA needs to verify the identity of the client.
- The client presents the certificate, and uses the private key known 
only to them to prove that the certificate belongs to them. Like a 
password, it is up to the client to protect the private key and no-one 
else, including the server admin should know the private key.


It doesn't matter if the man-in-the-middle has the certificate, because 
they can't use it without the private key. The private key is never 
transmitted, so no-one in the middle has the opportunity to intercept it.


It might be common for the server admin to generate the client 
certificates and keys because the alternative is hard to implement and 
manage, but it is roughly equivalent to sending passwords that the 
client is not allowed to change.


--
Andrew Rowley
Black Hill Software

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

Re: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Gibney, Dave]

It was in the early 80s. And, it might have been the Capex Optimizer we used 
then. Problem went away when he changed the installation option.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Mark Jacobs
> Sent: Thursday, August 29, 2019 1:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend
> 
> Surprising that the configuration of a COBOL compiler would care about a
> TMS, but OK.
> 
> Mark Jacobs
> 
> 
> Sent from ProtonMail, Swiss-based encrypted email.
> 
> GPG Public Key - https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__api.protonmail.ch_pks_lookup-3Fop-3Dget-26search-3Dmarkjacobs-
> 40protonmail.com=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8Ldrrv
> xQb-
> Je7sw=u9g8rUevBoyCPAdo5sWE9w=U2qQccZtMsqQaoMNAbjWOR02
> Qp8atllxid3_qEwkxU8=fw2jjw9a8rDskHNADpjpMFMsqVNhDGnEvi0_fmTs
> T4U=
> 
> ‐‐‐ Original Message ‐‐‐
> On Thursday, August 29, 2019 4:48 PM, Gibney, Dave 
> wrote:
> 
> > Very early. Fairly new at the job COBOL programming. Compiler was
> updated and started dying. I went a couple weeks round and round with the
> guy who did the install, trying to get him to open the issue with IBM. We
> were kind of formal in those days and he didn't believe the young
> newcomer.
> > I finally got him to let me see the installation options he'd used. One 
> > stood
> right out. There was a "tape management system' yes or no. He had no. I
> asked him what he thought CA-1 (well, then UCC-1) was..
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
> > > Behalf Of Edward Finnell
> > > Sent: Thursday, August 29, 2019 1:32 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler
> > > abend I saw one as  lab assistant. The bright young thing came
> > > tromping in 'the eight's broken, I need it fixed'. Turns out she was
> > > right! The adder's carry bit wasn't propagating. 3+3=6, 3+4=7, 4+4=7?
> Whoa nelly call the CE.
> > > In a message dated 8/29/2019 3:16:16 PM Central Standard Time,
> > > t...@tombrennansoftware.com writes:
> > > And I'm sure you can guess exactly how many of those times the
> > > system really turned out to be broken :)
> > >
> > > 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

SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue

[Farley, Peter x23353]

I have a confusing issue with using COBOL E15/E35 exit programs where the exit 
programs dynamically call application-specific subroutines in a JCL SYNCSORT.  
The issue is from which library the exit programs are actually loading the 
dynamically called subroutines.  It seems that the dynamic subroutines always 
load from LINKLIB, and not from STEPLIB or JOBLIB.  What I EXPECTED to happen 
was that the version of the dynamically called application-specific subroutines 
in the STEPLIB or JOBLIB would be used, not the version in LINKLIB.

The JCL sort in question has a STEPLIB pointing to a small PDS with 
application-specific versions of certain dynamically called subroutines.  The 
MODS statement is coded like this:

MODS E15=(EXITE15M,2048000,,C),E35=(EXITE35M,2048000,,C)

When each of the exits (both are compiled with Enterprise COBOL V5.2) EXITE15M 
or EXITE35M is called by SYNCSORT, the only version of those exit programs 
available is in the LINKLIST in a global application library.  Both exits 
dynamically call one of the application-specific subroutines as one of the 
first things that they do.

The application-specific subroutine performs a WTO as part of its normal 
operation (ROUTCDE=11,DESC=7) to allow identification of which version of the 
subroutine was actually loaded and executed.

Even with a STEPLIB (and I also tried a JOBLIB) pointing to a library with 
DIFFERENT VERSIONS of the application-specific subroutine than are in the 
global application library in the LINKLIST, only the GLOBAL VERSION in the 
LINKLIST application library is ever used, as evidenced by the WTO message 
generated.

Is this a misunderstanding on my part of how dynamic calls from a MODS exit 
program should work, or is this a potential issue for a call to SYNCSORT 
support?

SYNCSORT level is 2.1.6.0N, z/OS V2.2.

TIA for any assistance or advice you can provide.

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

Re: Assembler :- PC Instruction

[Jon Perryman]

 My point with ETCRE was that it is the start of the black box. You can't just 
depend upon this being a hardware only instruction nor can you rely upon your 
PC routine to be started directly from the instruction. IBM could easily pass 
your routine's address in another parm. Only someone who's looked at ETDEF 
could say for sure.

Jon.
On Thursday, August 29, 2019, 10:40:41 AM PDT, Seymour J Metz 
 wrote:  
 
 ETCRE et al are part of the setup prior to issuing the PC instruction; the 
actual implementation of the PC is a black box and need not be the same between 
models, as long as it complies with PoOps.


From: IBM Mainframe Discussion List  on behalf of Jon 
Perryman 


 For "who will perform the translation process", it's not going to be clear. 
First, rather than translation, the PC instruction builds the environment from 
the token. ETDEF defines the  PC environment but ETCRE or ETCON could easily 
insert calls into the environment entry without us being aware. P/OPS only 
tells us the hardware side and we don't have access to the internals (e.g. 
establishing ARR). So the answer is we can't say for sure.
  

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

Re: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Frank Swarbrick]

One reason to love Swift.  No semicolons required!!!


From: IBM Mainframe Discussion List  on behalf of 
Matt Hogstrom 
Sent: Thursday, August 29, 2019 12:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Case TS002648607 (PMR 76523,082,000) - Compiler abend

I always knew semi-colons were dangerous.  Most people butcher their usage in 
grammar and now abends … who knows what mischief they will stir up next.

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Aug 29, 2019, at 1:37 PM, Charles Mills  wrote:
>
> Amazing!
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Joseph Reichman
> Sent: Thursday, August 29, 2019 10:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend
>
> Begin forwarded message:
>
>> From: "Basil Kanneth" 
>> Date: August 29, 2019 at 11:01:57 AM EDT
>> To: "Joseph Reichman" 
>> Subject: RE: Case TS002648607 (PMR 76523,082,000) - Compiler abend
>>
>> Hi Joseph,
>>
>> It turns out the system protection exception occurred because of a missing 
>> semicolon after the following line in the code:
>> typedef int (DLL_FN)(char *)
>>
>> So it should be:
>> typedef int (DLL_FN)(char *);
>>
>> If you make the above changes, your test case should compile fine.
>>
>> We agree the compiler should not abend in this situation and we are 
>> investigating a potential fix.
>>
>> I will provide you with another update by Thursday, September 5th, 2019.
>>
>> Regards,
>> 
>> Basil Kanneth, PMP®
>> IBM XL C,C++, Fortran & COBOL Compilers Service Team
>> IBM Software Group - Toronto Lab

--
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: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Frank Swarbrick]

I've had the COBOL compiler abend during the SQL preprocessor step with a 
malformed EXEC SQL statement.


From: IBM Mainframe Discussion List  on behalf of 
Allan Staller 
Sent: Thursday, August 29, 2019 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Case TS002648607 (PMR 76523,082,000) - Compiler abend

Found another instance of the same thing many years ago. I forget if it was 
COBOL-E or COBOL-F.
A missing period caused the compiler to abend.

Ah! The good old days.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Thursday, August 29, 2019 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Case TS002648607 (PMR 76523,082,000) - Compiler abend

Amazing!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Thursday, August 29, 2019 10:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend

Begin forwarded message:

> From: "Basil Kanneth" 
> Date: August 29, 2019 at 11:01:57 AM EDT
> To: "Joseph Reichman" 
> Subject: RE: Case TS002648607 (PMR 76523,082,000) - Compiler abend
>
> Hi Joseph,
>
> It turns out the system protection exception occurred because of a missing 
> semicolon after the following line in the code:
> typedef int (DLL_FN)(char *)
>
> So it should be:
> typedef int (DLL_FN)(char *);
>
> If you make the above changes, your test case should compile fine.
>
> We agree the compiler should not abend in this situation and we are 
> investigating a potential fix.
>
> I will provide you with another update by Thursday, September 5th, 2019.
>
> Regards,
> 
> Basil Kanneth, PMP®
> IBM XL C,C++, Fortran & COBOL Compilers Service Team IBM Software
> Group - Toronto Lab
>
>
>
> From:"Joseph Reichman" 
> To:"'Basil Kanneth'" 
> Date:08/29/2019 08:16 AM
> Subject:[EXTERNAL] Re: Case TS002648607 (PMR 76523,082,000) - 
> Compiler abend
>
>
>
> Any updates
>
> 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
::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

Re: Assembler :- PC Instruction

[Jon Perryman]

 >>  The PC instruction is a replacement for SVC. 

> That's one use case. What about privileged code that scheduled an SRB into 
> another address space and waited for a cross-memory post? A PC is potentially 
> much less overhead.

PC routines are not necessary to use XMEM but they make it so easy, why bother 
setting up XMEM unless you absolutely need to run as fast as possible.



>> Both instructions exist solely to run authorized programs in other address 
>> spaces. 

> How did you run programs in another OS/360 address space. I don't see any 
> time machines here. ;-)
My bad for saying "other address space" when I meant "any address space". At 
least I didn't say existed.

Jon.

  

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

Re: Assembler :- PC Instruction

[Jon Perryman]

 Of course PC is the replacement for SVC. You have to look at SVC when PC came 
out and how it was being used. It doesn't matter what it was on OS/360. PC came 
out when address spaces and running authorized was available. Nearly every 
feature of PC was implemented to address use cases of SVC (e.g. xmem, 
limitations and restrictions). Even non-authorized came from an SVC use case 
(running non-authorized as much as possible).

Can you name any PC instruction features that don't fill a niche we needed in 
SVC? Remember that there were a lot of tricks we used to get around SVC's 
limitations.

As for "executing authorized code in other address spaces", I actually meant 
any address space. I was not thinking specifically about running code located 
in private which was another problem we had with SVC.

Jon.

On Thursday, August 29, 2019, 09:49:03 AM PDT, Tom Marchant 
<000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:  
 
 On Thu, 29 Aug 2019 04:22:02 +, Jon Perryman wrote:

>The PC instruction is a replacement for SVC.  Both instructions exist 
>solely to run authorized programs in other address spaces.

No. The SVC instruction, as implemented by OS/360 and its descendants, 
exists to provide a service that requires execution in Supervisor state. 
The concepts of address spaces and authorized programs didn't exist 
until years later.

While a common use case for PC routines is to execute code in another 
address space, that is not its only use case. Also, PC routines can be 
defined which receive control in problem state.

-- 
Tom Marchant

--
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: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Mark Jacobs]

Surprising that the configuration of a COBOL compiler would care about a TMS, 
but OK.

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Thursday, August 29, 2019 4:48 PM, Gibney, Dave  wrote:

> Very early. Fairly new at the job COBOL programming. Compiler was updated and 
> started dying. I went a couple weeks round and round with the guy who did the 
> install, trying to get him to open the issue with IBM. We were kind of formal 
> in those days and he didn't believe the young newcomer.
> I finally got him to let me see the installation options he'd used. One stood 
> right out. There was a "tape management system' yes or no. He had no. I asked 
> him what he thought CA-1 (well, then UCC-1) was..
>
> > -Original Message-
> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
> > Behalf Of Edward Finnell
> > Sent: Thursday, August 29, 2019 1:32 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend
> > I saw one as  lab assistant. The bright young thing came tromping in 'the
> > eight's broken, I need it fixed'. Turns out she was right! The adder's 
> > carry bit
> > wasn't propagating. 3+3=6, 3+4=7, 4+4=7? Whoa nelly call the CE.
> > In a message dated 8/29/2019 3:16:16 PM Central Standard Time,
> > t...@tombrennansoftware.com writes:
> > And I'm sure you can guess exactly how many of those times the system
> > really turned out to be broken :)
> >
> > 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: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Gibney, Dave]

   Very early. Fairly new at the job COBOL programming. Compiler was updated 
and started dying. I went a couple weeks round and round with the guy who did 
the install, trying to get him to open the issue with IBM. We were kind of 
formal in those days and he didn't believe the young newcomer.
   I finally got him to let me see the installation options he'd used. One 
stood right out. There was a "tape management system' yes or no. He had no. I 
asked him what he thought CA-1 (well, then UCC-1) was..

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Edward Finnell
> Sent: Thursday, August 29, 2019 1:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend
> 
> I saw one as  lab assistant. The bright young thing came tromping in 'the
> eight's broken, I need it fixed'. Turns out she was right! The adder's carry 
> bit
> wasn't propagating. 3+3=6, 3+4=7, 4+4=7? Whoa nelly call the CE.
> 
> In a message dated 8/29/2019 3:16:16 PM Central Standard Time,
> t...@tombrennansoftware.com writes:
> And I'm sure you can guess *exactly* how many of those times the system
> really turned out to be broken :)
> 
> --
> 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] Re: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Pommier, Rex]

I saw one on a BUNCH machine compiler, except that it didn't fail, it just gave 
the wrong result.  It was a fairly straightforward COMPUTE statement, something 
along the lines of COMPUTE D=C-(A*B).  The result came back as D=C+(A*B).  
Didn't take the company long to produce a fix for that one!

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Brennan
Sent: Thursday, August 29, 2019 3:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler 
abend

So many times I worked on a script or compiled/assembled code, got an error 
that made no sense, and then complained to anyone who would listen, "The system 
is obviously broken".  And I'm sure you can guess
*exactly* how many of those times the system really turned out to be broken :)

On 8/29/2019 10:27 AM, Joseph Reichman wrote:
> Begin forwarded message:
> 
>> From: "Basil Kanneth" 
>> Date: August 29, 2019 at 11:01:57 AM EDT
>> To: "Joseph Reichman" 
>> Subject: RE: Case TS002648607 (PMR 76523,082,000) - Compiler abend
>>
>> Hi Joseph,
>>
>> It turns out the system protection exception occurred because of a missing 
>> semicolon after the following line in the code:
>> typedef int (DLL_FN)(char *)
>>
>> So it should be:
>> typedef int (DLL_FN)(char *);
>>
>> If you make the above changes, your test case should compile fine.
>>
>> We agree the compiler should not abend in this situation and we are 
>> investigating a potential fix.
>>
>> I will provide you with another update by Thursday, September 5th, 2019.
>>
>> Regards,
>> 
>> Basil Kanneth, PMP®
>> IBM XL C,C++, Fortran & COBOL Compilers Service Team IBM Software 
>> Group - Toronto Lab

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

z/OS 2.1 to 2.4

[Gibney, Dave]

  I am considering what upgrade path (if any) I might take from my current z/OS 
2.1 RSU 1903 system. I thought that I wouldn't go to 2.3 because I was using 
SMTP and not CSSMTP. The configuring and implementation of CSSMTP has proven 
remarkably uneventful. I am not aware of any other gotchas between 2.1 and 2.3 
or above.
  I run four monoplex LPARs. I really don't "coexist" in the sysplex sense. I 
am considering getting s 2.4 Serverpac when available and making the jump.
  I do need to be concerned with fallback. I know it's mostly speculation at 
this point, but does anyone know of z/OS 2.4 fallback maintenance that won't be 
available for 2.1?
  Or gotchas I haven't noticed.

Dave Gibney
Information Technology Services
Washington State University


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

Re: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Edward Finnell]

I saw one as  lab assistant. The bright young thing came tromping in 'the 
eight's broken, I need it fixed'. Turns out she was right! The adder's carry 
bit wasn't propagating. 3+3=6, 3+4=7, 4+4=7? Whoa nelly call the CE. 

In a message dated 8/29/2019 3:16:16 PM Central Standard Time, 
t...@tombrennansoftware.com writes:
And I'm sure you can guess *exactly* how many of those times the system really 
turned out to be broken :)

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

Re: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Tom Brennan]

So many times I worked on a script or compiled/assembled code, got an 
error that made no sense, and then complained to anyone who would 
listen, "The system is obviously broken".  And I'm sure you can guess 
*exactly* how many of those times the system really turned out to be 
broken :)


On 8/29/2019 10:27 AM, Joseph Reichman wrote:

Begin forwarded message:


From: "Basil Kanneth" 
Date: August 29, 2019 at 11:01:57 AM EDT
To: "Joseph Reichman" 
Subject: RE: Case TS002648607 (PMR 76523,082,000) - Compiler abend

Hi Joseph,

It turns out the system protection exception occurred because of a missing 
semicolon after the following line in the code:
typedef int (DLL_FN)(char *)

So it should be:
typedef int (DLL_FN)(char *);

If you make the above changes, your test case should compile fine.

We agree the compiler should not abend in this situation and we are 
investigating a potential fix.

I will provide you with another update by Thursday, September 5th, 2019.

Regards,

Basil Kanneth, PMP®
IBM XL C,C++, Fortran & COBOL Compilers Service Team
IBM Software Group - Toronto Lab



From:"Joseph Reichman" 
To:"'Basil Kanneth'" 
Date:08/29/2019 08:16 AM
Subject:[EXTERNAL] Re: Case TS002648607 (PMR 76523,082,000) - Compiler 
abend



Any updates
  
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: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Jon Perryman]

 I expected this to be a missing paren causing the S0C4 but a semicolon is 
surprising. Usually you get a confusing message for a missing semicolon.

Notice that IBM says they will get back to you by Sept 5. You caused this guy 
extra work by declaring this a sev 1. I don't know about today but in the past, 
they were usually helpful without declaring an  unnecessary sev 1. In the 
future, try sev 2 and only raise to a sev 1 if you really need it.

Jon.

 On Thursday, August 29, 2019, 10:27:36 AM PDT, Joseph Reichman 
 wrote:  
 
 Begin forwarded message:

> From: "Basil Kanneth" 
> Date: August 29, 2019 at 11:01:57 AM EDT
> To: "Joseph Reichman" 
> Subject: RE: Case TS002648607 (PMR 76523,082,000) - Compiler abend
> 
> Hi Joseph,
> 
> It turns out the system protection exception occurred because of a missing 
> semicolon after the following line in the code:
> typedef int (DLL_FN)(char *)
> 
> So it should be:
> typedef int (DLL_FN)(char *);
> 
> If you make the above changes, your test case should compile fine.
> 
> We agree the compiler should not abend in this situation and we are 
> investigating a potential fix. 
> 
> I will provide you with another update by Thursday, September 5th, 2019.
> 
> Regards, 
> 
> Basil Kanneth, PMP®
> IBM XL C,C++, Fortran & COBOL Compilers Service Team
> IBM Software Group - Toronto Lab
> 
> 
> 
> From:        "Joseph Reichman" 
> To:        "'Basil Kanneth'" 
> Date:        08/29/2019 08:16 AM
> Subject:        [EXTERNAL] Re: Case TS002648607 (PMR 76523,082,000) - 
> Compiler abend
> 
> 
> 
> Any updates
>  
> 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: ILC of BAL, BALR

[Martin Packer]

That would correspond to 2 bytes and 4 bytes. Hence the word "code". 
(These lengths check out for BALR and BAL on the green card facsimiles 
hanging in a frame on the wall of my home office - that John Ehrman gave 
me.)

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Joseph Reichman 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   29/08/2019 15:47
Subject:ILC of BAL, BALR
Sent by:IBM Mainframe Discussion List 



Does this mean 

 

That BALR is length code 1 and BAL is  2 

 

And for BALR bit 32 is on BAL bit 33 is on

Thanks

 

 

---T--T-T-┐

│IL│ │Prog │ │

│C │CC│Mask │ Instruction Address │

L--+--+-+--

32 34 36 4 63

The instruction-length code is 1 or 2.

 

 

 

 

 

 


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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Matt Hogstrom]

I always knew semi-colons were dangerous.  Most people butcher their usage in 
grammar and now abends … who knows what mischief they will stir up next.

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Aug 29, 2019, at 1:37 PM, Charles Mills  wrote:
> 
> Amazing!
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Joseph Reichman
> Sent: Thursday, August 29, 2019 10:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend
> 
> Begin forwarded message:
> 
>> From: "Basil Kanneth" 
>> Date: August 29, 2019 at 11:01:57 AM EDT
>> To: "Joseph Reichman" 
>> Subject: RE: Case TS002648607 (PMR 76523,082,000) - Compiler abend
>> 
>> Hi Joseph,
>> 
>> It turns out the system protection exception occurred because of a missing 
>> semicolon after the following line in the code:
>> typedef int (DLL_FN)(char *)
>> 
>> So it should be:
>> typedef int (DLL_FN)(char *);
>> 
>> If you make the above changes, your test case should compile fine.
>> 
>> We agree the compiler should not abend in this situation and we are 
>> investigating a potential fix. 
>> 
>> I will provide you with another update by Thursday, September 5th, 2019.
>> 
>> Regards, 
>> 
>> Basil Kanneth, PMP®
>> IBM XL C,C++, Fortran & COBOL Compilers Service Team
>> IBM Software Group - Toronto Lab

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

Re: ILC of BAL, BALR

[Joseph Reichman]

Going to as soon as I m done with work 






On Aug 29, 2019, at 1:13 PM, Seymour J Metz  wrote:

>> In AMODE 24, BALR sets bit 32 to 0; 
> 
> Yes, and BAL sets it to 1, for the same reason. As I stated, "for 24-bit 
> mode, bits 32-33 are 01 after BALR and 10 after BAL"
> 
>> in AMODE 31 to 1.  I have used this to detect AMODE in code that had to run 
>> in
>> both XA and 370 without causing a program check.
> 
> Try that with a BAL instead of a BALR and see what happens. 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> Sent: Thursday, August 29, 2019 1:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ILC of BAL, BALR
> 
>> On Thu, 29 Aug 2019 16:54:15 +, Seymour J Metz wrote:
>> 
>> No, that means that for 24-bit mode, bits 32-33 are 01 after BALR and 10 
>> after BAL, per p. 6-7; the ILC is not stored for 31-bit and 64-bit modes.
>> 
> In AMODE 24, BALR sets bit 32 to 0; in AMODE 31 to 1.  I have used
> this to detect AMODE in code that had to run in both XA and 370 without
> causing a program check.
> 
> -- 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

Re: ILC of BAL, BALR

[Seymour J Metz]

> There are an infinite number of things that won't work.  Why should I try any 
> of them?

Because you brought up AMODE as if it were relevant to the ILC, and I was 
pointing out that it was irrelevant. 


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, August 29, 2019 1:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ILC of BAL, BALR

On Thu, 29 Aug 2019 17:13:35 +, Seymour J Metz wrote:

>> In AMODE 24, BALR sets bit 32 to 0;

Yes, and BAL sets it to 1, for the same reason. As I stated, "for 24-bit mode, 
bits 32-33 are 01 after BALR and 10 after BAL"

> in AMODE 31 to 1.  I have used this to detect AMODE in code that had to run in
> both XA and 370 without causing a program check.

Try that with a BAL instead of a BALR and see what happens.
>
There are an infinite number of things that won't work.  Why should
I try any of them?

And I no longer have a 370 and an XA to test with.

-- gil

(Why is LISTSERV WWW not quoting your text when I reply?)

--
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: vendor distributes their private key

[Seymour J Metz]

> But for certificate-based client authentication, the server admin must send 
> the client admin a client certificate AND its private key. 

Yes, he sends the client a key intended to be used only by that client. That's 
very different from a vendor sending his own private key to customers.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Wednesday, August 28, 2019 7:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key

I'm sure everyone is tired of this thread but I wanted to jump in here and say 
that anyone -- including me -- who said "you should never get a private key 
from the owners of some server you want to connect to" was potentially wrong.

Yes, yes, of course, sending out root CA or Intermediate certificate private 
keys is wrong, wrong, wrong. Horribly wrong. Ditto "regular" server certificate 
private keys.

But for certificate-based client authentication, the server admin must send the 
client admin a client certificate AND its private key. Why? Philosophically, 
because a client certificate signed by a trusted CA does not prove the 
authenticity of the client. A man-in-the-middle might have previously 
intercepted the certificate and now be sending it out from HIS client as its 
own.

Practically speaking, the client authentication protocol requires the client to 
send a certificate-signed hash of all of the messages that have come so far on 
the startup handshake. The server validates that signature with the public key 
in the certificate. The client must have the private key to be able to do that, 
preventing the MITM attack I describe above. And the fact that it uses the 
current session messages as a unique input prevents a replay type attack.

Here's a reference: 
https://blogs.msdn.microsoft.com/kaushal/2015/05/27/client-certificate-authentication-part-1/

Yeah, yeah, it's Microsoft but X.509 is X.509, even when Microsoft does it. 
Other references say the same thing. This was just more clear and thorough IMHO.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joel M Ivey
Sent: Thursday, August 22, 2019 5:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: vendor distributes their private key

A vendor has an ftps server for us to connect to from a batch job on zos.  
Similar setups with vendors have required the vendor to provide their server's 
public cert chain for import into RACF.   This vendor insists on providing not 
just their server public cert chain but also their private key.

First, they provided a password-protected p12 file, describing it as containing 
the "root, intermediate, and private certs".  I requested their public 
certificate chain only, they sent me a DER file -- with both the server cert 
and its private key.  I have asked them to elaborate on their need to 
distribute their private key to me, their response has essentially been, that's 
the way we do it.

I'm not comfortable accepting anyone's private key.   There has been no mention 
of "client authentication", and I'm still not sure I'd be comfortable with that 
config, either.

Help me understand two things: 1) what I'm missing as to why any vendor would 
require me to install their private key on my side when installing the public 
cert on my side should suffice as in many other instances, and 2) arguments 
for/against client authentication (not password authentication, but client) in 
case that is why they're sending me their private key.

Joel

--
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: ILC of BAL, BALR

[Paul Gilmartin]

On Thu, 29 Aug 2019 17:13:35 +, Seymour J Metz wrote:

>> In AMODE 24, BALR sets bit 32 to 0; 

Yes, and BAL sets it to 1, for the same reason. As I stated, "for 24-bit mode, 
bits 32-33 are 01 after BALR and 10 after BAL"

> in AMODE 31 to 1.  I have used this to detect AMODE in code that had to run in
> both XA and 370 without causing a program check.

Try that with a BAL instead of a BALR and see what happens. 
>
There are an infinite number of things that won't work.  Why should
I try any of them?

And I no longer have a 370 and an XA to test with.

-- gil

(Why is LISTSERV WWW not quoting your text when I reply?)

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

Re: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Allan Staller]

Found another instance of the same thing many years ago. I forget if it was 
COBOL-E or COBOL-F.
A missing period caused the compiler to abend.

Ah! The good old days.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Thursday, August 29, 2019 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Case TS002648607 (PMR 76523,082,000) - Compiler abend

Amazing!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Thursday, August 29, 2019 10:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend

Begin forwarded message:

> From: "Basil Kanneth" 
> Date: August 29, 2019 at 11:01:57 AM EDT
> To: "Joseph Reichman" 
> Subject: RE: Case TS002648607 (PMR 76523,082,000) - Compiler abend
>
> Hi Joseph,
>
> It turns out the system protection exception occurred because of a missing 
> semicolon after the following line in the code:
> typedef int (DLL_FN)(char *)
>
> So it should be:
> typedef int (DLL_FN)(char *);
>
> If you make the above changes, your test case should compile fine.
>
> We agree the compiler should not abend in this situation and we are 
> investigating a potential fix.
>
> I will provide you with another update by Thursday, September 5th, 2019.
>
> Regards,
> 
> Basil Kanneth, PMP®
> IBM XL C,C++, Fortran & COBOL Compilers Service Team IBM Software
> Group - Toronto Lab
>
>
>
> From:"Joseph Reichman" 
> To:"'Basil Kanneth'" 
> Date:08/29/2019 08:16 AM
> Subject:[EXTERNAL] Re: Case TS002648607 (PMR 76523,082,000) - 
> Compiler abend
>
>
>
> Any updates
>
> 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
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: Assembler :- PC Instruction

[Seymour J Metz]

ETCRE et al are part of the setup prior to issuing the PC instruction; the 
actual implementation of the PC is a black box and need not be the same between 
models, as long as it complies with PoOps.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Jon 
Perryman 
Sent: Thursday, August 29, 2019 12:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler :- PC Instruction

 For "who will perform the translation process", it's not going to be clear. 
First, rather than translation, the PC instruction builds the environment from 
the token. ETDEF defines the  PC environment but ETCRE or ETCON could easily 
insert calls into the environment entry without us being aware. P/OPS only 
tells us the hardware side and we don't have access to the internals (e.g. 
establishing ARR). So the answer is we can't say for sure.

Jon.

On Wednesday, August 28, 2019, 12:36:10 AM PDT, SUBSCRIBE IBM-MAIN 
Anonymous  wrote:

 Thanks for your response. Yes I agree that PC doesn't involve any 
interruption. "Principles of operations" manual clearly explains the PC 
translation process but I wanted to know "Who" will perform this translation 
process? For example we have "Dynamic Address translation" facility to 
transform Virtual addresses, and is there any similar facility to perform PC 
translation process.

--
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 :- PC Instruction

[Seymour J Metz]

>  The PC instruction is a replacement for SVC. 

That's one use case. What about privileged code that scheduled an SRB into 
another address space and waited for a cross-memory post? A PC is potentially 
much less overhead.

> Both instructions exist solely to run authorized programs in other address 
> spaces. 

How did you run programs in another OS/360 address space. I don't see any time 
machines here. ;-)

>  If I remember correctly,

You do; no SVRB, just a stack entry.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Jon 
Perryman 
Sent: Thursday, August 29, 2019 12:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler :- PC Instruction

 The PC instruction is a replacement for SVC.  Both instructions exist solely 
to run authorized programs in other address spaces. PC was designed to fix and 
simplify many of those problems with SVC. Some of the important problems 
addressed (not all):


1. 256 static defined SVC's replaced by dynamically assigned PC token that are 
fully under the products control without sysprog intervention (e.g. SVC table 
def).

2. SVC SRB replaced by simple xmem implementation that occurs automatically.

3. Abend recovery easily implemented in PC routine.

4. Eliminates the need for programs in CSA or SQA.

PC routines should run as fast (probably faster) as an SVC. If I remember 
correctly, >  If I remember correctly, PC's don't have an RB and use the 
linkage stack instead.

Jon.

On Wednesday, August 28, 2019, 09:23:28 AM PDT, Seymour J Metz 
 wrote:

 I doubt that PC was ever intended as a replacement for, e.g., BASR. How does 
its performance stack up against SVC?


--
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: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Charles Mills]

Amazing!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Thursday, August 29, 2019 10:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend

Begin forwarded message:

> From: "Basil Kanneth" 
> Date: August 29, 2019 at 11:01:57 AM EDT
> To: "Joseph Reichman" 
> Subject: RE: Case TS002648607 (PMR 76523,082,000) - Compiler abend
> 
> Hi Joseph,
> 
> It turns out the system protection exception occurred because of a missing 
> semicolon after the following line in the code:
> typedef int (DLL_FN)(char *)
> 
> So it should be:
> typedef int (DLL_FN)(char *);
> 
> If you make the above changes, your test case should compile fine.
> 
> We agree the compiler should not abend in this situation and we are 
> investigating a potential fix. 
> 
> I will provide you with another update by Thursday, September 5th, 2019.
> 
> Regards, 
> 
> Basil Kanneth, PMP®
> IBM XL C,C++, Fortran & COBOL Compilers Service Team
> IBM Software Group - Toronto Lab
> 
> 
> 
> From:"Joseph Reichman" 
> To:"'Basil Kanneth'" 
> Date:08/29/2019 08:16 AM
> Subject:[EXTERNAL] Re: Case TS002648607 (PMR 76523,082,000) - 
> Compiler abend
> 
> 
> 
> Any updates
>  
> 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: Assembler :- PC Instruction

[Seymour J Metz]

In this case the term "address space was generic", referring to the range of 
permissible numbers. SV


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Jon 
Perryman 
Sent: Thursday, August 29, 2019 12:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler :- PC Instruction

 PC does not have a larger address space. It simply has the option to access 
other address spaces.

Collisions for PC environments cannot occur because the PC instruction must use 
the token returned when you created the environment. The problem is passing 
this token to programs issuing the PC instruction.

I believe IBM has some statically defined PC tokens.

Jon.

On Wednesday, August 28, 2019, 10:35:07 AM PDT, Seymour J Metz 
 wrote:

 PC has a larger address space, but IBM still has to reserve numbers for its 
own use, and 3rd party vendors still must avoid collisions.



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

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

Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Joseph Reichman]

Begin forwarded message:

> From: "Basil Kanneth" 
> Date: August 29, 2019 at 11:01:57 AM EDT
> To: "Joseph Reichman" 
> Subject: RE: Case TS002648607 (PMR 76523,082,000) - Compiler abend
> 
> Hi Joseph,
> 
> It turns out the system protection exception occurred because of a missing 
> semicolon after the following line in the code:
> typedef int (DLL_FN)(char *)
> 
> So it should be:
> typedef int (DLL_FN)(char *);
> 
> If you make the above changes, your test case should compile fine.
> 
> We agree the compiler should not abend in this situation and we are 
> investigating a potential fix. 
> 
> I will provide you with another update by Thursday, September 5th, 2019.
> 
> Regards, 
> 
> Basil Kanneth, PMP®
> IBM XL C,C++, Fortran & COBOL Compilers Service Team
> IBM Software Group - Toronto Lab
> 
> 
> 
> From:"Joseph Reichman" 
> To:"'Basil Kanneth'" 
> Date:08/29/2019 08:16 AM
> Subject:[EXTERNAL] Re: Case TS002648607 (PMR 76523,082,000) - 
> Compiler abend
> 
> 
> 
> Any updates
>  
> thanks
> 
> 

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

Re: ILC of BAL, BALR

[Joseph Reichman]

I think I got 0 in the first byte after BAL Thanks got a reply for my C 
compiler issue will forward 



Joe Reichman
170-10 73 rd ave 
Fresh meadows NY 11366

> On Aug 29, 2019, at 12:54 PM, Seymour J Metz  wrote:
> 
> No, that means that for 24-bit mode, bits 32-33 are 01 after BALR and 10 
> after BAL, per p. 6-7; the ILC is not stored for 31-bit and 64-bit modes.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Joseph Reichman 
> Sent: Thursday, August 29, 2019 10:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ILC of BAL, BALR
> 
> Does this mean
> 
> 
> 
> That BALR is length code 1 and BAL is  2
> 
> 
> 
> And for BALR bit 32 is on BAL bit 33 is on
> 
> Thanks
> 
> 
> 
> 
> 
> ---T--T-T-┐
> 
> │IL│ │Prog │ │
> 
> │C │CC│Mask │ Instruction Address │
> 
> L--+--+-+--
> 
> 32 34 36 4 63
> 
> The instruction-length code is 1 or 2.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> 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: ILC of BAL, BALR

[Seymour J Metz]

> In AMODE 24, BALR sets bit 32 to 0; 

Yes, and BAL sets it to 1, for the same reason. As I stated, "for 24-bit mode, 
bits 32-33 are 01 after BALR and 10 after BAL"

> in AMODE 31 to 1.  I have used this to detect AMODE in code that had to run in
> both XA and 370 without causing a program check.

Try that with a BAL instead of a BALR and see what happens. 

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, August 29, 2019 1:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ILC of BAL, BALR

On Thu, 29 Aug 2019 16:54:15 +, Seymour J Metz wrote:

>No, that means that for 24-bit mode, bits 32-33 are 01 after BALR and 10 after 
>BAL, per p. 6-7; the ILC is not stored for 31-bit and 64-bit modes.
>
In AMODE 24, BALR sets bit 32 to 0; in AMODE 31 to 1.  I have used
this to detect AMODE in code that had to run in both XA and 370 without
causing a program check.

-- 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: Assembler :- PC Instruction

[Seymour J Metz]

> This begs a question for me how do you measure the performance..?

ObPedant ITYM raises.

There are several ways you can measure performance, but the key questions, as 
always, are "What do you mean by performance?" and "Performance of what?" Tell 
me the answer you want and I'll write the benchmark to prove it's correct.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
scott Ford 
Sent: Thursday, August 29, 2019 8:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler :- PC Instruction

Peter,

This begs a question for me how do you measure the performance..?
What I am seeing via the post and understanding performance matters even
with the faster Z processors.

Scott

On Thu, Aug 29, 2019 at 7:45 AM Peter Relson  wrote:

> 
> You can do a BASR and STORAGE OBTAIN, STORAGE RELEASE and BR in less time
> than a BAKR.
> 
>
> No you can't.
>
> 
> How does its performance stack up against SVC?
> 
>
> That's not a useful comparison. What is useful is "how does its
> performance stack up against SVC plus the SVC interrupt handler".
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Scott Ford
IDMWORKS
z/OS Development

--
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 :- PC Instruction

[Seymour J Metz]

SVC itself performs a simple function. SVC together with  its interrupt 
handlers is not so simple. What with the serialization for the GETMAIN or 
whatever it uses these days, I'd expect it to be at least as expensive as PC. 
If you need to operate in another address space, add in the overhead of 
acquiring, scheduling and freeing SRBs.

> The times that machine performance could be expressed in Million Instructions 
> Per Second are long gone.


They've been gone for half a century, if they ever existed.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Vernooij, Kees (ITOP NM) - KLM 
Sent: Thursday, August 29, 2019 8:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler :- PC Instruction

"against SVC plus the SVC interrupt handler".
Possibly also: Plus SVC code?
The SVC instruction performs a function, the PC instruction does too.

>From what I understood of the PC instruction: with 1 instruction you can now 
>execute a 'function' that might have taken pages of assembler instructions 
>before.

The times that machine performance could be expressed in Million Instructions 
Per Second are long gone.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Relson
> Sent: 29 August, 2019 13:45
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Assembler :- PC Instruction
>
> 
> You can do a BASR and STORAGE OBTAIN, STORAGE RELEASE and BR in less time
> than a BAKR.
> 
>
> No you can't.
>
> 
> How does its performance stack up against SVC?
> 
>
> That's not a useful comparison. What is useful is "how does its
> performance stack up against SVC plus the SVC interrupt handler".
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://secure-web.cisco.com/1yFCMng_oi34MeuWoGQVFSplOg6fpaFLyxdbGdQb9STPypzNLAxj2z3H1yPe4hmcGsoQrveXhGIGpIQn4y5avwq7BULLqLr7LDIdVd3uZfyPSdpqKPZLOf85a9_UOdAfEEkGjPnXcTp7oZjO72UlCrOrkWCx9XGTouvxIvkrdhdxx7mbiJCUcsSNwdIhGoKmSm_S4VqyCCu_-5BvvEZ79ciMla-Ce6L9JM5Ftywxolu5eN46Eq6qEk2Cf-Zcs5T9IkVQzK7gnyAmr3_tZBL1XW1EDny_9mYCBo58WeWGmKDzZaHMjFOWAKa7le7wuJMXxvxGhuhm_EyVpP7hsmqb89fuquitBk3uYlWjLHQFCW51CPwAUMtM3_g4RZTozHtzb/http%3A%2F%2Fwww.klm.com.
 This e-mail and any attachment may contain confidential and privileged 
material intended for the addressee only. If you are not the addressee, you are 
notified that no part of the e-mail or any attachment may be disclosed, copied 
or distributed, and that any other action related to this e-mail or attachment 
is strictly prohibited, and may be unlawful. If you have received this e-mail 
by error, please notify the sender immediately by return e-mail, and delete 
this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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

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

Re: ILC of BAL, BALR

[Paul Gilmartin]

On Thu, 29 Aug 2019 16:54:15 +, Seymour J Metz wrote:

>No, that means that for 24-bit mode, bits 32-33 are 01 after BALR and 10 after 
>BAL, per p. 6-7; the ILC is not stored for 31-bit and 64-bit modes.
>
In AMODE 24, BALR sets bit 32 to 0; in AMODE 31 to 1.  I have used
this to detect AMODE in code that had to run in both XA and 370 without
causing a program check.

-- gil

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

Re: ILC of BAL, BALR

[Seymour J Metz]

No, that means that for 24-bit mode, bits 32-33 are 01 after BALR and 10 after 
BAL, per p. 6-7; the ILC is not stored for 31-bit and 64-bit modes.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Thursday, August 29, 2019 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ILC of BAL, BALR

Does this mean



That BALR is length code 1 and BAL is  2



And for BALR bit 32 is on BAL bit 33 is on

Thanks





---T--T-T-┐

│IL│ │Prog │ │

│C │CC│Mask │ Instruction Address │

L--+--+-+--

32 34 36 4 63

The instruction-length code is 1 or 2.














--
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 :- PC Instruction

[Tom Marchant]

On Thu, 29 Aug 2019 04:22:02 +, Jon Perryman wrote:

>The PC instruction is a replacement for SVC.  Both instructions exist 
>solely to run authorized programs in other address spaces.

No. The SVC instruction, as implemented by OS/360 and its descendants, 
exists to provide a service that requires execution in Supervisor state. 
The concepts of address spaces and authorized programs didn't exist 
until years later.

While a common use case for PC routines is to execute code in another 
address space, that is not its only use case. Also, PC routines can be 
defined which receive control in problem state.

-- 
Tom Marchant

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

Re: Migrate MQ from 7.0.1 to 9.1

[David Spiegel]

Hi Dana and Andy,
You can omit (ZPARM) OPMODE and let it default as a first attempt.
You can code MEMLIMIT=3G, provided that OPMODE is set to either 
(NEWFUNC,800) or (NEWFUNC,900) (in a later attempt).
You should also code REGION=0M in the MSTR Proc.

Just before shutting down the Queue Manager, issue DISPLAY Commands (in 
a batch job) which will allow you to re-create MQ entities (offloaded in 
Command format).
Before doing anything, it is prudent to back up (with the Queue Manager 
down) all MQ VSAM Datasets (e.g. BSDS, Pagesets) before starting up the 
Queue Manager with the new level of software.

Regards,
David

On 2019-08-29 11:55, Andy Cooper wrote:
> Hi, Dana...
>
> I did this exact upgrade last year when our shop upgraded z/OS v1.13 to v2.2. 
>  As far as I remember, this upgrade only needed an MQ parm changed for the 
> correct / new version - can't recall what parm it was, but I'm sure you can 
> find it.  Didn't have to change anything else, and the upgrade was 
> successful, especially when you consider your "vanilla" system.  Beware 
> though...at least in my experience, we ran into problems trying to go back to 
> v7 (due to a problem with the z/OS upgrade and that might have had everything 
> to do with the MQ problems at the time).  All in all, again, to the best of 
> my memory, one parm change...point to the new MQ libraries...test / verify MQ 
> queue connections...and you should be good to go!
>
>
> Andy
>
> --
> 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: Problems downloading z/OS 2.2 PDFs from //publibz.boulder.ibm.com

[Susan Shumway]

Yes, it looks like you unfortunately landed on a temporary server issue 
- everything seems to work fine now. Please let me know if you run into 
similar glitches that aren't resolved within a few hours and I'll alert 
the appropriate team/s.


-Sue Shumway


On 8/27/2019 4:54 PM, Mike Hochee wrote:

Thanks for checking.  I'm thinking IBM is working on it now, as I can no longer 
get to the MVS feature download page.


From: IBM Mainframe Discussion List  on behalf of Paul 
Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, August 27, 2019 3:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Problems downloading z/OS 2.2 PDFs from //publibz.boulder.ibm.com

On Tue, 27 Aug 2019 19:07:45 +, Mike Hochee wrote:


Hi, I suspect an IBM doc server issue.  Downloads of PDFs from IBM z/OS V2R2 
Elements and Features PDF Downloads ( 
https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosv2r2-pdf-download?OpenDocument
 ) from the z/OS MVS shelf ( 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.iea/iea.htm
 ) and then I select the PDF link for the Authorized Assember Services 
Reference ALE-DYN ( http://publibz.boulder.ibm.com/epubs/pdf/iea3a110.pdf )  
Then I wait for minutes without seeing much progress on the download status bar 
and eventually close the session.

IBM z/OS V2R2 Elements and Features (PDF 
Downloads)
www-01.ibm.com
z/OS V2R2 Elements and Features - PDF Downloads





The problem is not with one manual, nor one feature shelf within z/OS 2.2, but 
appears to be all features.

z/OS 2.3 does not have this issue.

IBM z/OS V2R2 Elements and Features (PDF 
Downloads)
www-01.ibm.com
z/OS V2R2 Elements and Features - PDF Downloads


I see it as intermittent:

547 $ time curl 
https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosv2r2-pdf-download?OpenDocument
 | wc
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:--  0:00:29 --:--:-- 
0curl: (6) Could not resolve host: www-01.ibm.com
0   0   0

real0m30.626s
user0m0.009s
sys 0m0.009s
548 $
548 $ time curl 
https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosv2r2-pdf-download?OpenDocument
 | wc
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
100 18742  100 187420 0   2591  0  0:00:07  0:00:07 --:--:--  3924
  4621153   18742

real0m7.253s
user0m0.019s
sys 0m0.015s
549 $

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



--
Sue Shumway
z/OS Product Documentation Lead
IBM Poughkeepsie
chale...@us.ibm.com

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

Re: Migrate MQ from 7.0.1 to 9.1

[Andy Cooper]

Hi, Dana...

I did this exact upgrade last year when our shop upgraded z/OS v1.13 to v2.2.  
As far as I remember, this upgrade only needed an MQ parm changed for the 
correct / new version - can't recall what parm it was, but I'm sure you can 
find it.  Didn't have to change anything else, and the upgrade was successful, 
especially when you consider your "vanilla" system.  Beware though...at least 
in my experience, we ran into problems trying to go back to v7 (due to a 
problem with the z/OS upgrade and that might have had everything to do with the 
MQ problems at the time).  All in all, again, to the best of my memory, one 
parm change...point to the new MQ libraries...test / verify MQ queue 
connections...and you should be good to go!


Andy

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

Re: PDSE DELETE PENDING

[Paul Gilmartin]

On Thu, 29 Aug 2019 06:34:34 -0500, Steve Horein wrote:
>
>Much better.
>While I can't help with the question of "what really happens...", it does
>seem that -something- must happen to the PDSE to allow successful deletion
>of those members. In the case of this particular NetView data set, "REACC"
>appears to be that thing. Perhaps in the case of LLA managed data sets, it
>would be the "F LLA,UPDATE=..."?
>
After a program has issued BLDL or DESERV, PDSE is obliged to assume that
any members returned are in use until the program issues STOW DISC.
I surmise that REACC (sounds like CMS jargon) issues the DISC.

Does NetView gain any performance benefit by hoarding TTRs rather than
issuing DISC sooner?

-- gil

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

Re: Clarification on DASD mod conversion of SYSRES

[Michael Babcock]

I just checked my master cat and EVERY entry has , 2, or 3 except
SYS1.PARMLIB on the SYSRES It has **. and  both are set
to  since we use mod 27s.   We are at z/OS 2.3.

On Thu, Aug 29, 2019 at 12:17 AM Barbara Nitz  wrote:

> >I have never has a problem using  anywhere ** could have been
> used.
> >Actually, the resolution of  occurs very early in the IPL, long
> before CAS is initialized.
> >
> >The difference is that  is resolved by CAS, which is not yet
> initialized at that moment. Until then, ** does the built-in
> substitution.
>
> The non-full-function CAS address space used to start way after LPA and
> Linklist are built. When I had LPA and Linklist data sets catalogued on
> volume  (z/OS 1.13), the IPL essentially failed, because LPA was
> rather empty and also Linklist only had the automatically added libraries
> in it. Very hard to get a system up that way.
>
> There used to be a gap in the asid numbers (IIRC, it was a missing number
> 8) that was the non-full-function asid. When I just checked z/OS 2.3, that
> gap is gone. So either there isn't an early CAS anymore (the full-function
> CATALOG asid has number x'2B') or the early CAS uses REUSEASID=YES or the
> startup sequence was completely rewritten.
>
> In any case, when I check the VOLUME parm for DEFINE NONVSAM, it still
> reads to me that volume ** covers the sysres volume and  is
> supposed to be used for *extensions* of the sysres volume. This reads:
> "The symbol name is intended to represent the volume that is a logical
> extension of the system residence volume.
> ... IBM recommends the use of the symbol  for the first logical
> extension to the system reference volume,  for the second, and so on."
>
> So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres
> catalogued to volume  instead of volume ** ???
>
> Barbara
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
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

Re: Assembler :- PC Instruction

[Jon Perryman]

 > how do you measure the performance..?


For the PC instruction, performance is simply a curiosity and doesn't really 
matter. The alternatives are SVC and SSI. The benefits of PC far outweigh any 
possible savings by using SVC. The SSI is a special use case. 

As for measuring performance, is there any possible metric that would be 
meaningful and useful? Do you ignore some instruction options? Do you include 
OS support routines that are included after the instruction complete's (e.g. 
SVC interrupt handler).

Jon.. 

On Thursday, August 29, 2019, 05:19:04 AM PDT, scott Ford 
 wrote:  
 
 Peter,

This begs a question for me how do you measure the performance..?
What I am seeing via the post and understanding performance matters even
with the faster Z processors.

Scott

On Thu, Aug 29, 2019 at 7:45 AM Peter Relson  wrote:

> 
> You can do a BASR and STORAGE OBTAIN, STORAGE RELEASE and BR in less time
> than a BAKR.
> 
>
> No you can't.
>
> 
> How does its performance stack up against SVC?
> 
>
> That's not a useful comparison. What is useful is "how does its
> performance stack up against SVC plus the SVC interrupt handler".
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

--
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: Clarification on DASD mod conversion of SYSRES

[Jousma, David]

I got curious.   Looks like ** and  are interchangeable for 
everything with one restriction noted below

RTFMing in Init & Tuning: 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieae200/ieae20035.htm

I see the following restrictions for indirect cataloging:

Indirect volume serial support can only be used for data sets residing on 
SYSRES and its logical extensions. These are typically data sets that are 
installed as part of a system build process. Use with user or application data 
sets is not supported.
Cataloged data sets must be non-VSAM and non-SMS-managed.
The volume must be mounted and online when a request is made to retrieve 
information from the catalog.
You are responsible for managing volumes where the data sets reside. If you 
move a data set from one volume to another, you must make the related changes. 
Changes include:
setting up parmlib, proclib, and JCL.
establishing system management procedures such as security, backup, and 
recovery.


The following cannot be catalogued with a system symbol:
SYS1.PARMLIB
Any parmlib data set listed in LOADxx without a volume name.
Any parmlib data set (including SYS1.PARMLIB) can be catalogued with six 
asterisks (**).

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Matthew Stitt
Sent: Thursday, August 29, 2019 9:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Clarification on DASD mod conversion of SYSRES

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I mis-wrote.

My LPALSTxx and PROGxx do not utilized the  variable.  Only on the APF 
statements is it used.  Sorry for the confusion.

All the datasets except for the VSAM (ZFS) on my the volume I use for SMP/E 
target and IPL are cataloged with  for the volume name.  Even 
SYS1.NUCLEUS, SYS1.LPALIB, and SYS1.LINKLIB, which must be on the IPL volume 
anyway.  Except for SYS1.PARMLIB and SYS1.PROCLIB, which are cataloged using 
** for the volume name.  I've had IPL issues when not using that 
convention.  But usage of that special volume name implies they are on the IPL 
volume.

On Thu, 29 Aug 2019 12:49:47 +, David Spiegel  
wrote:

>Hi Matthew,
>That is not the same as CATALOGing Datasets to VOL().
>
>Regards,
>David
>
>On 2019-08-29 08444, Matthew Stitt wrote:
>> On my systems, I use the volume parameter of the LPALSTxx, PROGxx, etc.  
>> Volume is set to  (or  (on mod-54, so not needed now) ).  Have 
>> no issues with IPL using this method.
>>
>> Matthew
>>
>> On Thu, 29 Aug 2019 10:58:15 +, Richards, Robert B. 
>>  wrote:
>>
 So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres 
 catalogued to volume  instead of volume ** ???
>>> Not in my shop (z/OS 2.3). All my references to  are all contained 
>>> in IEASYM00 and are used to substring its first four characters for the 
>>> setting of , etc.
>>>
>>> Bob
>

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

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

ILC of BAL, BALR

[Joseph Reichman]

Does this mean 

 

That BALR is length code 1 and BAL is  2 

 

And for BALR bit 32 is on BAL bit 33 is on

Thanks

 

 

---T--T-T-┐

│IL│ │Prog │ │

│C │CC│Mask │ Instruction Address │

L--+--+-+--

32 34 36 4 63

The instruction-length code is 1 or 2.

 

 

 

 

 

 


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

Re: ISKLM problems - kind of related to mainframe

[Pommier, Rex]

Hi list,

Just wanted to circle back for closure on this in case somebody else hits the 
same snag.  We're using something called CyberArk to monitor and log all 
privileged access to Windows servers (and soon coming to Linux here).  The SKLM 
documentation says to perform the install as a local admin on a Windows box.  
The process I was doing was logging in using CyberArk, then trying to do the 
install using Windows' "run as another user" function.  This didn't work.  I 
had to have my Windows admin activate RDP to the SKLM servers and allow me to 
log on directly using the local admin account I had set up then run the install 
as a "run as administrator".  I could not find this restriction anywhere in the 
SKLM manuals but kudos to Alan and Steve from the IBM support center for their 
timely assistance in resolving this issue for me.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Thursday, August 22, 2019 4:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] ISKLM problems - kind of related to mainframe

Hello,

Is there somebody on the list who would be willing to give me a hand installing 
ISKLM 3.0.1?  I'm trying to install it on a brand new windows 2016 box and the 
DB2 install is failing with 

SQL30082N  Security processing failed with reason "19" ("USERID DISABLED or 
RESTRICTED").  SQLSTATE=08001

This is at the end of the db2 install log.

The ID sklmdb31 was defined before starting the install and defined as a local 
admin on the machine (not a domain ID at all) and the install added the 
sklmdb31 ID to the DB2ADMINS group as part of the install, but then it dies 
saying some USERID is DISABLED.  What ID are they talking about and how do I 
get past this error?   The messages give me no indication that I've found to 
tell me what ID they're talking about.  

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

Re: Assembler :- PC Instruction

[scott Ford]

Kees good point

On Thu, Aug 29, 2019 at 8:29 AM Vernooij, Kees (ITOP NM) - KLM <
kees.verno...@klm.com> wrote:

> "against SVC plus the SVC interrupt handler".
> Possibly also: Plus SVC code?
> The SVC instruction performs a function, the PC instruction does too.
>
> From what I understood of the PC instruction: with 1 instruction you can
> now execute a 'function' that might have taken pages of assembler
> instructions before.
>
> The times that machine performance could be expressed in Million
> Instructions Per Second are long gone.
>
> Kees.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Peter Relson
> > Sent: 29 August, 2019 13:45
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Assembler :- PC Instruction
> >
> > 
> > You can do a BASR and STORAGE OBTAIN, STORAGE RELEASE and BR in less time
> > than a BAKR.
> > 
> >
> > No you can't.
> >
> > 
> > How does its performance stack up against SVC?
> > 
> >
> > That's not a useful comparison. What is useful is "how does its
> > performance stack up against SVC plus the SVC interrupt handler".
> >
> > Peter Relson
> > z/OS Core Technology Design
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: [External] Re: Clarification on DASD mod conversion of SYSRES

[Pommier, Rex]

Hi Barbara,

z/OS 2.2, SYS1.PARMLIB cataloged using **, SYS1.PROCLIB not on the res 
volume, everything else cataloged to   It works fine.  I'll keep your 
warning about PARMLIB in the back of my mind and not try something dumb like 
recataloging it to  when we go to 2.4 next year.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Barbara Nitz
Sent: Thursday, August 29, 2019 12:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Clarification on DASD mod conversion of SYSRES

>I have never has a problem using  anywhere ** could have been used.
>Actually, the resolution of  occurs very early in the IPL, long before 
>CAS is initialized.
>
>The difference is that  is resolved by CAS, which is not yet initialized 
>at that moment. Until then, ** does the built-in substitution.

The non-full-function CAS address space used to start way after LPA and 
Linklist are built. When I had LPA and Linklist data sets catalogued on volume 
 (z/OS 1.13), the IPL essentially failed, because LPA was rather empty 
and also Linklist only had the automatically added libraries in it. Very hard 
to get a system up that way.

There used to be a gap in the asid numbers (IIRC, it was a missing number 8) 
that was the non-full-function asid. When I just checked z/OS 2.3, that gap is 
gone. So either there isn't an early CAS anymore (the full-function CATALOG 
asid has number x'2B') or the early CAS uses REUSEASID=YES or the startup 
sequence was completely rewritten. 

In any case, when I check the VOLUME parm for DEFINE NONVSAM, it still reads to 
me that volume ** covers the sysres volume and  is supposed to be 
used for *extensions* of the sysres volume. This reads:
"The symbol name is intended to represent the volume that is a logical 
extension of the system residence volume.
... IBM recommends the use of the symbol  for the first logical extension 
to the system reference volume,  for the second, and so on."

So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres 
catalogued to volume  instead of volume ** ???

Barbara

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


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

Re: GIM23901E clarification - packaging error

[Lizette Koehler]

Any potential packaging error should be reported to the vendor.

Lizette



> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Jake Anderson
> Sent: Wednesday, August 28, 2019 9:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: GIM23901E clarification
> 
> Hi David,
> 
> Thank you so much
> 
> I was able to track down via the sequence number and it turned out to be a
> DDDEF missing.
> 
> I did receive another related message for RMF module but I feel it's a
> packaging error and I would like to get an opinion on this
> 
> For example
> 
> UA91794
> Message ID : GIM23901E
> Error : Link-edit processing failed for module ERBEXCRY in LMOD ERBRMFPX in
> the SERBLINK Library. The return code was 08. The sequence number was 02
> 
> From SYSPRINT :
> IEW2470E 9511 ORDERED SECTION ERBRMFPP NOT FOUND IN MODULE.
> 
> 
> I feel this could be a PTF packaging issue and prior raising PMR with IBM.
> Just wanted check in Group if someone has received similar message while
> applying RSU1907.
> 
> Regards
> Jake
> 
> 
> On Wed, 28 Aug, 2019, 2:43 PM Jousma, David, < 01a0403c5dc1-dmarc-
> requ...@listserv.ua.edu> wrote:
> 
> > Go find the output of the linkedit at sequence number 29.  You will
> > find the actual error there.
> >
> >
> > __
> > ___
> > Dave Jousma
> > AVP | Manager, Systems Engineering
> >
> > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> > Rapids, MI 49546
> > 616.653.8429  |  fax: 616.653.2717
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Jake Anderson
> > Sent: Wednesday, August 28, 2019 4:06 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: GIM23901E clarification
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or
> > unexpected emails**
> >
> > Hi All,
> >
> > While applying RSU on zOS 2.2 I received
> >
> > GIM23901E ** LINK-EDIT PROCESSING FOR SYSMOD UA80355 FAILED FOR MODULE
> > GFSAAOBT IN LMOD GFSAMAIN IN THE NFSLIBE LIBRARY. THE RETURN CODE (8)
> > EXCEEDED THE ALLOWABLE VALUE DATE 19.420 - TIME 11:52:10 - SEQUENCE
> > NUMBER
> > 29
> >
> > I am trying to understand the explanation for return code 8.
> >
> > Can someone please direct me ?
> >
> > Jake
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or
> > unexpected emails**
> >
> > 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

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

Re: Clarification on DASD mod conversion of SYSRES

[Matthew Stitt]

I mis-wrote.

My LPALSTxx and PROGxx do not utilized the  variable.  Only on the APF 
statements is it used.  Sorry for the confusion.

All the datasets except for the VSAM (ZFS) on my the volume I use for SMP/E 
target and IPL are cataloged with  for the volume name.  Even 
SYS1.NUCLEUS, SYS1.LPALIB, and SYS1.LINKLIB, which must be on the IPL volume 
anyway.  Except for SYS1.PARMLIB and SYS1.PROCLIB, which are cataloged using 
** for the volume name.  I've had IPL issues when not using that 
convention.  But usage of that special volume name implies they are on the IPL 
volume.

On Thu, 29 Aug 2019 12:49:47 +, David Spiegel  
wrote:

>Hi Matthew,
>That is not the same as CATALOGing Datasets to VOL().
>
>Regards,
>David
>
>On 2019-08-29 08444, Matthew Stitt wrote:
>> On my systems, I use the volume parameter of the LPALSTxx, PROGxx, etc.  
>> Volume is set to  (or  (on mod-54, so not needed now) ).  Have 
>> no issues with IPL using this method.
>>
>> Matthew
>>
>> On Thu, 29 Aug 2019 10:58:15 +, Richards, Robert B. 
>>  wrote:
>>
 So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres 
 catalogued to volume  instead of volume ** ???
>>> Not in my shop (z/OS 2.3). All my references to  are all contained 
>>> in IEASYM00 and are used to substring its first four characters for the 
>>> setting of , etc.
>>>
>>> Bob
>

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

Re: COW for fork() is disappearing in z/OS 2.4

[Jerry Callen]

David Crayford says...

> ...It would be fantastic to have bash as the default shell for z/OS but that
> ain't gonna happen anytime soon :)

FWIW: Here's how I tend to work on z/OS.

* I leave my default login shell (in the OMVS segment) as /bin/sh.
* I have my .profile/.bash_profile/.bashrc files set up to switch me to bash
   immediately (though my files are set up to work with /bin/sh , just in case).
* I usually write shell scripts with a #!/bin/sh shebang (giving up some bash
   features in scripts).

It works for me. I get bash interactive behavior, but my scripts don't require 
bash.
Yes, a compromise, but one I consider acceptable. The Rocket bash port has
some advantages in a mixed-encoding environment (_BPXK_AUTOCVT=ON).

Since I run nearly all my shells in an emacs buffer anyway, shell interactive 
behavior
isn't something I usually care much about anyway. :-)

-- Jerry

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

Re: vendor distributes their private key

[Todd Arnold]

> crypto non-repudiation can show it came from your machine

I certainly agree with this, but you can restrict what "your machine" is so 
that it's a lot better than just "came from a particular PC" or "came from a 
particular mainframe".  For example, the private key may be stored in something 
you carry and control yourself, like a smart card or cell phone (maybe even the 
secure enclave in the phone), and digital signatures can be computed in that 
same device.  The smart card can be PIN-protected, and similarly a cell phone 
can require authentication.  This isn't 100% secure, but it's not bad in most 
cases - there are several possible attack vectors, but they generally aren't 
easy.  On the mainframe, of course, you can use something like RACF to control 
access to / use of the private key.  Again, not perfect by any means, but not 
bad.

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

Re: Clarification on DASD mod conversion of SYSRES

[David Spiegel]

Hi Matthew,
That is not the same as CATALOGing Datasets to VOL().

Regards,
David

On 2019-08-29 08:44, Matthew Stitt wrote:
> On my systems, I use the volume parameter of the LPALSTxx, PROGxx, etc.  
> Volume is set to  (or  (on mod-54, so not needed now) ).  Have no 
> issues with IPL using this method.
>
> Matthew
>
> On Thu, 29 Aug 2019 10:58:15 +, Richards, Robert B. 
>  wrote:
>
>>> So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres 
>>> catalogued to volume  instead of volume ** ???
>> Not in my shop (z/OS 2.3). All my references to  are all contained in 
>> IEASYM00 and are used to substring its first four characters for the setting 
>> of , etc.
>>
>> Bob
>>
> --
> 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: Clarification on DASD mod conversion of SYSRES

[Matthew Stitt]

On my systems, I use the volume parameter of the LPALSTxx, PROGxx, etc.  Volume 
is set to  (or  (on mod-54, so not needed now) ).  Have no issues 
with IPL using this method.

Matthew

On Thu, 29 Aug 2019 10:58:15 +, Richards, Robert B. 
 wrote:

>> So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres 
>> catalogued to volume  instead of volume ** ???
>
>Not in my shop (z/OS 2.3). All my references to  are all contained in 
>IEASYM00 and are used to substring its first four characters for the setting 
>of , etc.   
>
>Bob
>

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

Re: Assembler :- PC Instruction

[Vernooij, Kees (ITOP NM) - KLM]

"against SVC plus the SVC interrupt handler".
Possibly also: Plus SVC code?
The SVC instruction performs a function, the PC instruction does too.

>From what I understood of the PC instruction: with 1 instruction you can now 
>execute a 'function' that might have taken pages of assembler instructions 
>before.

The times that machine performance could be expressed in Million Instructions 
Per Second are long gone.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Relson
> Sent: 29 August, 2019 13:45
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Assembler :- PC Instruction
> 
> 
> You can do a BASR and STORAGE OBTAIN, STORAGE RELEASE and BR in less time
> than a BAKR.
> 
> 
> No you can't.
> 
> 
> How does its performance stack up against SVC?
> 
> 
> That's not a useful comparison. What is useful is "how does its
> performance stack up against SVC plus the SVC interrupt handler".
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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

Re: Assembler :- PC Instruction

[scott Ford]

Peter,

This begs a question for me how do you measure the performance..?
What I am seeing via the post and understanding performance matters even
with the faster Z processors.

Scott

On Thu, Aug 29, 2019 at 7:45 AM Peter Relson  wrote:

> 
> You can do a BASR and STORAGE OBTAIN, STORAGE RELEASE and BR in less time
> than a BAKR.
> 
>
> No you can't.
>
> 
> How does its performance stack up against SVC?
> 
>
> That's not a useful comparison. What is useful is "how does its
> performance stack up against SVC plus the SVC interrupt handler".
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Assembler :- PC Instruction

[Peter Relson]

You can do a BASR and STORAGE OBTAIN, STORAGE RELEASE and BR in less time 
than a BAKR. 


No you can't.


How does its performance stack up against SVC? 


That's not a useful comparison. What is useful is "how does its 
performance stack up against SVC plus the SVC interrupt handler". 

Peter Relson
z/OS Core Technology Design


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

Re: PDSE DELETE PENDING

[Steve Horein]

I was unaware of the PERFORMPENDINGDELETE option. Nice.
Anecdotal: I'm a automation administrator, and have struggled with
NetView's DSILIST data set that is used to retain various automation table
listings/reports. IBM recommends allocating this data set as a PDSE to
avoid Sx37 ABENDs and/or the need to compress. Well, guess what?

IEC031I D37-04,IGG0210B,NETVIEW,NETVIEW,SYS89298,602D,SH9DAK,
NETVIEW.NET97.DSILIST(INGMRT01)

IEC217I B14-0C,IGG0201Z,NETVIEW,NETVIEW,SYS89298,602D,SH9DAK,
NETVIEW.NET97.DSILIST(INGMRT01)

I don't have the result of IEBPDSE, but if I recall, there were 83 pending
deletes at the time. This is on a test system, so nothing I was terribly
concerned with.
After reading your question, I exercised "PERFORMPENDINGDELETE" with the
following result:

IGW705I Pending Delete Records Processed
 Pending Delete Members deleted
Out of 0014 possible

What?! 
NetView has a "REACC" command that does some magic in the background (
https://www.ibm.com/support/knowledgecenter/SSZJDU_6.2.1/com.ibm.itnetviewforzos.doc_6.2.1/dqc_reacc.htm).
Other doc references for the REACC command include: "If the data set
becomes full and you must compress the data set to add more command lists,
use the REACC command...".
I issued REACC and attempted "PERFORMPENDINGDELETE" again, with the
following result:

IGW705I Pending Delete Records Processed
0014 Pending Delete Members deleted
Out of 0014 possible

Much better.
While I can't help with the question of "what really happens...", it does
seem that -something- must happen to the PDSE to allow successful deletion
of those members. In the case of this particular NetView data set, "REACC"
appears to be that thing. Perhaps in the case of LLA managed data sets, it
would be the "F LLA,UPDATE=..."?


On Thu, Aug 29, 2019 at 12:06 AM Kenneth J. Kripke 
wrote:

> The url
>
> https://www.ibm.com/support/pages/pdse-member-pending-delete-processing-over
> view  indicates that when executing IEBPDSE with the
> PARM='PERFORMPENDINGDELETE,NOANALYSIS'
>
> Seems to imply that space will be released for deleted members.  We do
> routine maintenance on various Linklist datasets and follow-up with an LLA
> UPDATE of the respective libraries on all LPARS.  We have not tested the
> IEBPDSE PERFORMPENDELETE,NOANALYSIS Yet, but will do so in the near future.
> My question:  How does this really work, and, what really has to happen to
> reclaim the deleted space.
>
> Sincerely;
>
>
>
> Kenneth J. Kripke
>
>
>
> k.kri...@comcast.net
>
>
>
>
> --
> 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: PDSE DELETE PENDING

[Tabari Alexander]

One of the differences between PDSes and PDSEs is that PDSEs reclaim the space 
of deleted members. In order for that to be done, however, the PDSE address 
space needs to know that the member is no longer in use so it is safe for the 
space to be reclaimed. If the space cannot be reclaimed at the time of 
deletion, which is typical if the PDSE is LLA managed, there are other 
opportunities where PDSE will try to reclaim the space as part of normal 
processing. IEBPDSE with the PerformPendingDelete parameter is a means to force 
the processing to occur. Please do note that this process will still only 
reclaim space from deleted members that are not in use. 

Tabari

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

GlobalCopy SMF

[Sankaranarayanan, Vignesh]

Hello!

Global Copy bytes transferred (Out of Sync)... is this available in SMF 
anywhere, by any chance?

- Vignesh
Mainframe Infrastructure


MARKSANDSPENCER.COM

Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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

Re: Clarification on DASD mod conversion of SYSRES

[Richards, Robert B.]

> So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres 
> catalogued to volume  instead of volume ** ???

Not in my shop (z/OS 2.3). All my references to  are all contained in 
IEASYM00 and are used to substring its first four characters for the setting of 
, etc.   

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barbara Nitz
Sent: Thursday, August 29, 2019 1:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Clarification on DASD mod conversion of SYSRES

>I have never has a problem using  anywhere ** could have been used.
>Actually, the resolution of  occurs very early in the IPL, long before 
>CAS is initialized.
>
>The difference is that  is resolved by CAS, which is not yet initialized 
>at that moment. Until then, ** does the built-in substitution.

The non-full-function CAS address space used to start way after LPA and 
Linklist are built. When I had LPA and Linklist data sets catalogued on volume 
 (z/OS 1.13), the IPL essentially failed, because LPA was rather empty 
and also Linklist only had the automatically added libraries in it. Very hard 
to get a system up that way.

There used to be a gap in the asid numbers (IIRC, it was a missing number 8) 
that was the non-full-function asid. When I just checked z/OS 2.3, that gap is 
gone. So either there isn't an early CAS anymore (the full-function CATALOG 
asid has number x'2B') or the early CAS uses REUSEASID=YES or the startup 
sequence was completely rewritten. 

In any case, when I check the VOLUME parm for DEFINE NONVSAM, it still reads to 
me that volume ** covers the sysres volume and  is supposed to be 
used for *extensions* of the sysres volume. This reads:
"The symbol name is intended to represent the volume that is a logical 
extension of the system residence volume.
... IBM recommends the use of the symbol  for the first logical extension 
to the system reference volume,  for the second, and so on."

So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres 
catalogued to volume  instead of volume ** ???

Barbara

--
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: vendor distributes their private key

[Mike Wawiorko]

OH, read this again.

I retract my comment - I didn't spot the reference to mutual authentication.

There would be an alternative for the server end to trust a client certificate 
signed by the client's CA by trusting the client's root CA.

Mike Wawiorko   


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Wawiorko
Sent: 29 August 2019 10:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key


This mail originated from outside our organisation - 
014ab5cdfb21-dmarc-requ...@listserv.ua.edu

Charles sent this

"But for certificate-based client authentication, the server admin must send 
the client admin a client certificate AND its private (???) key."

Surely that should say public key. Or am I missing something?

Mike Wawiorko   I   Mainframe Connectivity   I   Global Technology 
Infrastructure and Services Tel  +44 (0)330 1535515    I   Internal  81535515   
I   Mobile  +44 (0)7824 527120 Email  mike.wawio...@barclays.com Barclays, 
Wilson Technology Lab GB12, BTC Radbroke, WA16 9EU (Mail Van 49) barclays.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: 29 August 2019 00:19
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key


...

But for certificate-based client authentication, the server admin must send the 
client admin a client certificate AND its private key. Why? Philosophically, 
because a client certificate signed by a trusted CA does not prove the 
authenticity of the client. A man-in-the-middle might have previously 
intercepted the certificate and now be sending it out from HIS client as its 
own.
...

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

Re: vendor distributes their private key

[Mike Wawiorko]

Charles sent this

"But for certificate-based client authentication, the server admin must send 
the client admin a client certificate AND its private (???) key."

Surely that should say public key. Or am I missing something?

Mike Wawiorko   I   Mainframe Connectivity   I   Global Technology 
Infrastructure and Services
Tel  +44 (0)330 1535515    I   Internal  81535515   I   Mobile  +44 (0)7824 
527120
Email  mike.wawio...@barclays.com
Barclays, Wilson Technology Lab GB12, BTC Radbroke, WA16 9EU (Mail Van 49) 
barclays.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: 29 August 2019 00:19
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key


...

But for certificate-based client authentication, the server admin must send the 
client admin a client certificate AND its private key. Why? Philosophically, 
because a client certificate signed by a trusted CA does not prove the 
authenticity of the client. A man-in-the-middle might have previously 
intercepted the certificate and now be sending it out from HIS client as its 
own.
...

Charles


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

Re: Assembler :- PC Instruction

[Rob Scott]

>> PC has a larger address space, but IBM still has to reserve numbers for its 
>> own use, and 3rd party vendors still must avoid collisions.

Avoid collisions?

PC number is formed by ETE sequence number suffixed to LX number returned by 
LXRES.

As someone who has written quite a few software products that provide PC 
routines, I have never had to worry about collisions with IBM (or other ISV) 
software.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, August 28, 2019 6:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler :- PC Instruction

PC has a larger address space, but IBM still has to reserve numbers for its own 
use, and 3rd party vendors still must avoid collisions.


--
Shmuel (Seymour J.) Metz
https://nam01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7Cdc0dd6d386f14dd64c6708d72bde10d2%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637026105076814212sdata=g0T%2FxZM94KxBQ0MVmkG%2B1WyyUxqsn6v4qL8W6cuyMfU%3Dreserved=0



From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Wednesday, August 28, 2019 1:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler :- PC Instruction

Correct me if I am wrong. I don't pretend to be an expert on this subject.

I think of SVCs as hailing from the era of centralized monolithic operating 
system construction. I would guess that IBM had an "SVC number committee"
and they sat down and said "SVC 1 shall do this; SVC 2 shall do that; and so 
forth." Yes, you can add a user SVC, but fundamentally the SVC has a fixed 
architecture of 256 possibilities, requiring some sort of central 
administration. Chris and I cannot both add an SVC 201 to our customers'
computers. (Yes, having the number in a config file would be a workaround.)

PCs are inherently much more decentralized. There can be a nearly unlimited 
number of PCs. Chris and I can both add a PC to our customers' computers 
without much fear of a collision.

And yes, not to disagree with what Chris says, the architecture of SVC is more 
suited to a single address space, or at least an addressing scheme in which all 
"privileged services" are at least partially resident in common address space.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Christopher Y. Blaicher
Sent: Wednesday, August 28, 2019 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler :- PC Instruction

Never measured SVC vs PC.  While in some cases PC and SVC are similar, in many 
ways PC is far superior to SVC.  It can be local or globally defined and it can 
be dynamically defined and removed.  (OK, so can an SVC be added and deleted, 
but I think PC's are easier).
Also, an SVC can't do space switching.

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

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


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

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