Re: File access from remote systems

[Jim Ruddy]

There is a product called Distributed FileManager/MVS  which I believe used
to have a Windows client (1997) but now only seems to support OS/2, AS400,
and AIX. For more info look at
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idag200/d9069.htm
to see if this is what you are looking for. There are probably folks on
here with some experience - I only had some very old manuals for reference
for a prototype I built while in IBM (which never saw the light of day) -
these led me to search and find the z/OS 2.1 manual above.

Jim

On Wed, Apr 4, 2018 at 11:11 AM, Ward, Mike S  wrote:

> No not a remote z/OS, but a distributed system. I.E. Intel and such.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: Wednesday, April 04, 2018 11:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: File access from remote systems
>
> W dniu 2018-04-03 o 19:44, Ward, Mike S pisze:
> > Hello all, does anyone know of any software that allows access to VSAM,
> SEQ, CICS files from remote systems. I.E. distributed systems. How is the
> access done? Web service calls? MQ calls?
>
> Remote z/OS ? ;-)))
>
> Two free (built in) options:
> * DFS/SMB - you z/OS is like Windows file server. Acceptable for read,
> poor for update.
> * NFS - good for Unix/Linux and Windows.
>
>
> BTW: It's very fine to show people how to open VSAM KSDS - just using
> notepad ;-)
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> ==
>
>
> --
>  Treść tej wiadomości może zawierać informacje prawnie chronione Banku
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś
> adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej
> przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie
> zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo,
> prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale
> usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
>  This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee
> authorized to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility in
> your e-mail software and delete permanently this e-mail including any
> copies of it either printed or saved to hard drive.
>
>  mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru
> przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień
> 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi
> 169.248.488 złotych.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ==
> This email, and any files transmitted with it, is confidential and
> intended solely for the use of the individual or entity to which it is
> addressed. If you have received this email in error, please notify the
> system manager. This message contains confidential information and is
> intended only for the individual named. If you are not the named addressee,
> you should not disseminate, distribute or copy this e-mail. Please notify
> the sender immediately by e-mail if you have received this message by
> mistake and delete this e-mail from your system. If you are not the
> intended recipient, you are notified that disclosing, copying, distributing
> or taking any action in reliance on the contents of this information is
> strictly prohibited.
>
> --
> 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: Zconnect

[Timothy Sipples]

Len Sasso wrote:
>I'm sorry, but I meant accessing, via a REST API, an external
>Website and downloading a file from the external site?

You could use either the z/OS Client Web Enablement Toolkit (for basic
function) or z/OS Connect Enterprise Edition (fuller function) to do that.
z/OS would then be the "client," and you'd be accessing a REST API
somewhere else -- provided by some other system, which could be anything
(including another z/OS system).

As an aside, that's not really the highest, best use of REST APIs.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: sipp...@sg.ibm.com

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

Re: Software Delivery on Tape to be Discontinued

[Charles Mills]

I guess you would call that "issuing a certificate."

Certificates -- the entire certificate -- are  signed. They include a public 
key.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Rowley
Sent: Wednesday, April 4, 2018 8:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software Delivery on Tape to be Discontinued

On 5/04/2018 1:01 PM, Charles Mills wrote:
> Keys are not signed, at least not generally.
>
> Messages may be signed; a process that involves two keys.

What do you call it then when I generate a key pair and submit the public key 
to a CA, they perform some form of verification and return a certificate to use 
with TLS etc?

I would have said the certificate includes a signed public key, but I admit I 
am far from an expert on this stuff.

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

Re: Software Delivery on Tape to be Discontinued

[Andrew Rowley]

On 5/04/2018 1:01 PM, Charles Mills wrote:

Keys are not signed, at least not generally.

Messages may be signed; a process that involves two keys.


What do you call it then when I generate a key pair and submit the 
public key to a CA, they perform some form of verification and return a 
certificate to use with TLS etc?


I would have said the certificate includes a signed public key, but I 
admit I am far from an expert on this stuff.


--
Andrew Rowley
Black Hill Software
+61 413 302 386

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

Re: Security (was: Software Delivery on Tape ...)

[Charles Mills]

Three months may be the new normal. That is all that LetsEncrypt is doing.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lester, Bob
Sent: Wednesday, April 4, 2018 4:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Security (was: Software Delivery on Tape ...)

Hi Folks,

  As someone who is currently dealing with this - replacing unexpired 
certificates (to the Digicert Intermediate/CA from the Symantec CA) for our F5s 
and back-end servers, I can tell you that this is a pain in my butt.   Can't 
renew while replacing unless within 90 days of expiration, so you have to 
replace and then renew in some cases.  Not too bad for internal stuff, but not 
fun for external parters due to the coordination involved.

  Near as I can tell from the information I getting (from Symantec and 
others), it's not going to get better anytime soon.  From what I've heard, some 
folks are advocating a 90-day certificate renewal.  While I don't have an issue 
with that, it may make automation more important for larger enterprises.

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

Re: Software Delivery on Tape to be Discontinued

[Charles Mills]

> Whether the key itself is signed by a CA

Keys are not signed, at least not generally.

Messages may be signed; a process that involves two keys.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Rowley
Sent: Wednesday, April 4, 2018 3:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software Delivery on Tape to be Discontinued

On 4/04/2018 11:02 PM, Alan Altmark wrote:
> Because you accessed the web site via https://, causing the transmission of 
> the key to be encrypted and tamper-proof.  Further, Charles' web site uses a 
> certificate published by a Certificate Authority that YOU trust.  Or more 
> precisely, he uses a CA that the vendor of your browser trusts.  You trust 
> your vendor implicitly by using their browser.
>
> THAT is what CA/Browser Forum (CAB) industry group is all about.
Right, but I was just nitpicking the statement that a public key on a website 
doesn't require a CA.

Whether the key itself is signed by a CA, or a second key used to establish a 
secure session to get the first key is signed by a CA, a CA is still involved.

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

Re: Security (was: Software Delivery on Tape ...)

[Lester, Bob]

Hi Folks,

  As someone who is currently dealing with this - replacing unexpired 
certificates (to the Digicert Intermediate/CA from the Symantec CA) for our F5s 
and back-end servers, I can tell you that this is a pain in my butt.   Can't 
renew while replacing unless within 90 days of expiration, so you have to 
replace and then renew in some cases.  Not too bad for internal stuff, but not 
fun for external parters due to the coordination involved.

  Near as I can tell from the information I getting (from Symantec and 
others), it's not going to get better anytime soon.  From what I've heard, some 
folks are advocating a 90-day certificate renewal.  While I don't have an issue 
with that, it may make automation more important for larger enterprises.

 Well, maybe it will keep me employed for a bit longer...   

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, April 4, 2018 5:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Security (was: Software Delivery on Tape ...) [ EXTERNAL ]

On Wed, 4 Apr 2018 15:57:02 -0700, Charles Mills wrote:

>> As for Certificate Authorities, quis custodiet ipsos custodes?
>
>Google LOL.
>https://urldefense.proofpoint.com/v2/url?u=https-3A__security.googleblo
>g.com_2017_09_chromes-2Dplan-2Dto-2Ddistrust-2Dsymantec.html=DwIFaQ
>=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k=1KMMjoSvFEwY7ZoooplFIrKc
>OeeTJVI4X6Bc3o6vdK4=viCmiUgiqpvJal6JWxEjJfdIBtZkBEuWqPhowJfEyzY=WdX
>KZvrW1WkWZcxmVv-1pngWRoNEYa6LNpqZJIga6Og=
> 
How will that be removed from my Firefox?  Routinely, with updates, or will it 
be irrelevant once all servers stop relying on it?  LOL.

-- gi

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

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.


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

Re: Security (was: Software Delivery on Tape ...)

[Paul Gilmartin]

On Wed, 4 Apr 2018 15:57:02 -0700, Charles Mills wrote:

>> As for Certificate Authorities, quis custodiet ipsos custodes?
>
>Google LOL.
>https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html 
> 
How will that be removed from my Firefox?  Routinely, with updates, or
will it be irrelevant once all servers stop relying on it?  LOL.

-- gi

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

Re: Software Delivery on Tape to be Discontinued

[Paul Gilmartin]

On Thu, 5 Apr 2018 08:56:04 +1000, Andrew Rowley wrote:

>...  You trust your vendor implicitly by using their browser.
>>
>> THAT is what CA/Browser Forum (CAB) industry group is all about.
>Right, but I was just nitpicking the statement that a public key on a
>website doesn't require a CA.
>
>Whether the key itself is signed by a CA, or a second key used to
>establish a secure session to get the first key is signed by a CA, a CA
>is still involved.
> 
I'll fall back to Charles's nostalgic assertion, 
"..., before the use of SSL/TLS browsing was widespread, the idea was that
my public key was "public knowledge."
I recall those halcyon days when a frequent dialog on BBSes was:
"Will you sign my PGP key?"
"No."

-- gil

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

Re: Security (was: Software Delivery on Tape ...)

[Charles Mills]

> As for Certificate Authorities, quis custodiet ipsos custodes?

Google LOL.
https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, April 4, 2018 3:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Security (was: Software Delivery on Tape ...)

On Wed, 4 Apr 2018 17:34:45 -0500, Walt Farrell wrote:
>
>Of course, you want a checksum method that is strong enough that an attacker 
>can't create a modified file that will have the same checksum. SHA-1 is no 
>longer strong enough to guarantee that, from what I've read. SHA-2 should be 
>strong enough.
>
That would be a preimage attack.  I believe

https://crypto.stackexchange.com/questions/53638/feasible-pre-image-attacks-against-reduced-sha-1

... doubts the feasibility of a preimage attach on SHA-1.  And even

https://security.stackexchange.com/questions/170789/md5-preimage-vulnerability-in-2017

... seems to say that MD5 is susceptible largely for short passwords.  
Mitigation is either longer passwords or slower encryption algorithms.  If the 
password is shorter than the key, it's quicker to do an exhaustive search of 
passwords than of keys.
Access to the database of encrypted passwords facilitates the attack.

As for Certificate Authorities, quis custodiet ipsos custodes?

-- 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: Software Delivery on Tape to be Discontinued

[Andrew Rowley]

On 4/04/2018 11:02 PM, Alan Altmark wrote:

Because you accessed the web site via https://, causing the transmission of the 
key to be encrypted and tamper-proof.  Further, Charles' web site uses a 
certificate published by a Certificate Authority that YOU trust.  Or more 
precisely, he uses a CA that the vendor of your browser trusts.  You trust your 
vendor implicitly by using their browser.

THAT is what CA/Browser Forum (CAB) industry group is all about.
Right, but I was just nitpicking the statement that a public key on a 
website doesn't require a CA.


Whether the key itself is signed by a CA, or a second key used to 
establish a secure session to get the first key is signed by a CA, a CA 
is still involved.


--
Andrew Rowley
Black Hill Software
+61 413 302 386

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

Security (was: Software Delivery on Tape ...)

[Paul Gilmartin]

On Wed, 4 Apr 2018 17:34:45 -0500, Walt Farrell wrote:
>
>Of course, you want a checksum method that is strong enough that an attacker 
>can't create a modified file that will have the same checksum. SHA-1 is no 
>longer strong enough to guarantee that, from what I've read. SHA-2 should be 
>strong enough.
>
That would be a preimage attack.  I believe

https://crypto.stackexchange.com/questions/53638/feasible-pre-image-attacks-against-reduced-sha-1

... doubts the feasibility of a preimage attach on SHA-1.  And even

https://security.stackexchange.com/questions/170789/md5-preimage-vulnerability-in-2017

... seems to say that MD5 is susceptible largely for short passwords.  
Mitigation is
either longer passwords or slower encryption algorithms.  If the password is 
shorter
than the key, it's quicker to do an exhaustive search of passwords than of keys.
Access to the database of encrypted passwords facilitates the attack.

As for Certificate Authorities, quis custodiet ipsos custodes?

-- gil

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

Re: Software Delivery on Tape to be Discontinued

[Walt Farrell]

On Wed, 4 Apr 2018 10:54:04 +1000, Andrew Rowley  
wrote:

>On 4/04/2018 10:29 AM, Paul Gilmartin wrote:
>> So is a signature any more secure than an independently verifiable checksum,
>> or just more practical?
>If you get the checksum via a reliable channel I think it is as secure.
>The digital signature allows the checksum to be included with the file,
>and verified using pre-arranged public keys. So you only need the public
>keys rather than a means to get a verifiable checksum for each package
>(really the signature + public keys are the means to verify the checksum).

Of course, you want a checksum method that is strong enough that an attacker 
can't create a modified file that will have the same checksum. SHA-1 is no 
longer strong enough to guarantee that, from what I've read. SHA-2 should be 
strong enough.

-- 
Walt

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

Re: [External] Getting a VOLSER for a disk that is a member of a copy pair

[Bill Wilkie]

The doc says online, offline and both earlier in the doc.

Sent from my iPhone

> On Apr 4, 2018, at 3:42 PM, Pommier, Rex  wrote:
> 
> Actually I think an English major would disagree with your documentation 
> assessment.  3-Either means if it is either online or offline, add it to the 
> list, 3-Both says it has to be both online and offline to get included.  :-)
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Bill Wilkie
> Sent: Wednesday, April 04, 2018 2:09 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Getting a VOLSER for a disk that is a member of a copy 
> pair
> 
> I have a program that reads VOLSERS for offline volumes. It works fine for 
> several flavors of VM and Z/OS, and returns the data in a few MS. But takes a 
> minute when issued to a device in a copy pair. If I issue it a second time, 
> it runs fast, so I suppose it could be coming from CACHE or some bit has 
> changed that allows for the faster I/o or it gets the VOLSER form a control 
> block.
> 
> 
> I noticed that when I use the ISMF screen in ISPF option 2.1 it comes Up 
> right away. So If there is anyone listening from the ISMF group, can you tell 
> me if you do I/O to get the volser or do you get it from a control block 
> somewhere.  It would be greatly appreciated.
> 
> 
> BTW, I just sent in a correction to the manual for ISMF. Here is a line from 
> the screen:
> 
> 
> Type of Volume List . . . 2  (1-Online,2-Not Online,3-Either)
> 
> 
> I think it should be 1 for ONLINE, 2 for OFFLINE and 3 for BOTH(not either).
> 
> 
> Thanks
> 
> 
> 
> --
> 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

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

Re: [External] Getting a VOLSER for a disk that is a member of a copy pair

[Pommier, Rex]

Actually I think an English major would disagree with your documentation 
assessment.  3-Either means if it is either online or offline, add it to the 
list, 3-Both says it has to be both online and offline to get included.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Wilkie
Sent: Wednesday, April 04, 2018 2:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Getting a VOLSER for a disk that is a member of a copy pair

I have a program that reads VOLSERS for offline volumes. It works fine for 
several flavors of VM and Z/OS, and returns the data in a few MS. But takes a 
minute when issued to a device in a copy pair. If I issue it a second time, it 
runs fast, so I suppose it could be coming from CACHE or some bit has changed 
that allows for the faster I/o or it gets the VOLSER form a control block.


I noticed that when I use the ISMF screen in ISPF option 2.1 it comes Up right 
away. So If there is anyone listening from the ISMF group, can you tell me if 
you do I/O to get the volser or do you get it from a control block somewhere.  
It would be greatly appreciated.


BTW, I just sent in a correction to the manual for ISMF. Here is a line from 
the screen:


Type of Volume List . . . 2  (1-Online,2-Not Online,3-Either)


I think it should be 1 for ONLINE, 2 for OFFLINE and 3 for BOTH(not either).


Thanks



--
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: Explanation about the SVCASF bit ("SVC can be assisted") in the SVC table?

[Dori Polotsky]

Thank you both for the historical perspective, and special thanks to Jim
for the additional up-to-date clarification - it now makes much more sense.

Best regards,
 Dori


On Wed, Apr 4, 2018 at 8:44 PM, Jim Mulder  wrote:

>   SVC Assist has not been used since MVS/ESA SP3.1.0 (30 years ago),
> so the SVCASF bit has had no meaning for 30 years.  It is on in the
> SVC 13  and SVC 26 entries because of some obsolete code in
> IEAVNPS5,  which should have been deleted.  However, this causes
> no harm, since the bit is not used for anything.
>
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> Poughkeepsie NY
>
> IBM Mainframe Discussion List  wrote on
> 04/04/2018 11:33:07 AM:
>
> > From: Rob Scott 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 04/04/2018 12:36 PM
> > Subject: Re: Explanation about the SVCASF bit ("SVC can be
> > assisted") in the SVC table?
> > Sent by: IBM Mainframe Discussion List 
> >
> > "SVC Assist" is a facility that performed some common housekeeping
> > operations on behalf of the SVC - for example,  copying the information
> > stored at the last SVC interruption into the current request block,
> > saving general registers, and loading the general registers with
> > appropriate values.
> >
> > It was implemented by opcode x'E503'.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> > ] On Behalf Of Dori Polotsky
> > Sent: Wednesday, April 4, 2018 10:18 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Explanation about the SVCASF bit ("SVC can be assisted") in
> > the SVC table?
> >
> > Hello,
> >
> > Does anyone know the meaning of the SVCASF bit (x'01') of the SVCTP
> > byte of the SVC table?
> >
> > If I am not mistaken, on our system (z/OS 2.2 ADCD) following the
> > IPL this bit is off for all SVC's except SVC 13 (ABEND, IEAVTRT2)
> > and SVC 26 (LOCATE / CATALOG, IGG026DU).  Also, I did not see an
> > option to select the value for this bit with SVCUPDTE.
> >
> > Any insights would be appreciated.
> >
> > Thank you very much,
> >   Dori
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
[image: Model9]
Dori Polotsky
R
m: +972-54-4584663  e: dori.polot...@model9.io   w: www.model9.io

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

Getting a VOLSER for a disk that is a member of a copy pair

[Bill Wilkie]

I have a program that reads VOLSERS for offline volumes. It works fine for 
several flavors of VM and Z/OS, and returns the data in a few MS. But takes a 
minute when issued to a device in a copy pair. If I issue it a second time, it 
runs fast, so I suppose it could be coming from CACHE or some bit has changed 
that allows for the faster I/o or it gets the VOLSER form a control block.


I noticed that when I use the ISMF screen in ISPF option 2.1 it comes Up right 
away. So If there is anyone listening from the ISMF group, can you tell me if 
you do I/O to get the volser or do you get it from a control block somewhere.  
It would be greatly appreciated.


BTW, I just sent in a correction to the manual for ISMF. Here is a line from 
the screen:


Type of Volume List . . . 2  (1-Online,2-Not Online,3-Either)


I think it should be 1 for ONLINE, 2 for OFFLINE and 3 for BOTH(not either).


Thanks



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

Re: Software Delivery on Tape to be Discontinued

[Charles Mills]

Yep, that's what TLS does.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, April 4, 2018 9:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software Delivery on Tape to be Discontinued

W dniu 2018-04-04 o 17:34, Charles Mills pisze:
>> IBM sign the hash (in fact they sign whole serverpac)
> I think the "whole serverpac" is effectively signed -- but the way that is 
> done is to sign the hash. There are security advantages too long a digression 
> for this reply.
>
>> If you really want to encrypt the content (ie. DVD files) then you 
>> have to make your pair of PRIVATE/PUBLIC keys. Yes, the customer has 
>> to do it and ask IBM to use his public key
> Yep, that is the process that certificates and the TLS protocol automate. TLS 
> does not do anything for you in terms of encryption that you could not do on 
> your own -- but worst case doing it without TLS would require your sending a 
> courier with a briefcase containing a secret key locked to his wrist to IBM, 
> and IBM maintaining a secret key for each customer. TLS automates that 
> process, securely.

NO!
Asymmetric crypto is the solution for secret key exchange. There is no longer 
need to exchange the keys using briefcase.
I keep my private key in secret and my public key is really public. You do the 
same with your key pair. Now I can encrypt (but NOT DECRYPT) some data using 
your public key and only private key holder can decrypt it (you). And vice 
versa - you can encrypt some data using my public key.
In case of doubt who is on the other end of wire (am I using YOUR key or 
someone else's key?)  certificates can be used.

Note: asymmetric cryptography is very cpu-consuming, approx. 1000 times more 
than symmetric. That's why people (protocols) tend to use asymmetric cyrpto to 
exchange small data portion - the key, symmetric one. After that both parties 
share their own, unique, disposable key for bulk data exchange.

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

Re: File access from remote systems

[Ward, Mike S]

No not a remote z/OS, but a distributed system. I.E. Intel and such.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, April 04, 2018 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File access from remote systems

W dniu 2018-04-03 o 19:44, Ward, Mike S pisze:
> Hello all, does anyone know of any software that allows access to VSAM, SEQ, 
> CICS files from remote systems. I.E. distributed systems. How is the access 
> done? Web service calls? MQ calls?

Remote z/OS ? ;-)))

Two free (built in) options:
* DFS/SMB - you z/OS is like Windows file server. Acceptable for read, poor for 
update.
* NFS - good for Unix/Linux and Windows.


BTW: It's very fine to show people how to open VSAM KSDS - just using
notepad ;-)

--
Radoslaw Skorupka
Lodz, Poland




==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: Explanation about the SVCASF bit ("SVC can be assisted") in the SVC table?

[Jim Mulder]

  SVC Assist has not been used since MVS/ESA SP3.1.0 (30 years ago), 
so the SVCASF bit has had no meaning for 30 years.  It is on in the 
SVC 13  and SVC 26 entries because of some obsolete code in 
IEAVNPS5,  which should have been deleted.  However, this causes 
no harm, since the bit is not used for anything. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

IBM Mainframe Discussion List  wrote on 
04/04/2018 11:33:07 AM:

> From: Rob Scott 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 04/04/2018 12:36 PM
> Subject: Re: Explanation about the SVCASF bit ("SVC can be 
> assisted") in the SVC table?
> Sent by: IBM Mainframe Discussion List 
> 
> "SVC Assist" is a facility that performed some common housekeeping 
> operations on behalf of the SVC - for example,  copying the information
> stored at the last SVC interruption into the current request block, 
> saving general registers, and loading the general registers with 
> appropriate values.
> 
> It was implemented by opcode x'E503'.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ] On Behalf Of Dori Polotsky
> Sent: Wednesday, April 4, 2018 10:18 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Explanation about the SVCASF bit ("SVC can be assisted") in
> the SVC table?
> 
> Hello,
> 
> Does anyone know the meaning of the SVCASF bit (x'01') of the SVCTP 
> byte of the SVC table?
> 
> If I am not mistaken, on our system (z/OS 2.2 ADCD) following the 
> IPL this bit is off for all SVC's except SVC 13 (ABEND, IEAVTRT2) 
> and SVC 26 (LOCATE / CATALOG, IGG026DU).  Also, I did not see an 
> option to select the value for this bit with SVCUPDTE.
> 
> Any insights would be appreciated.
> 
> Thank you very much,
>   Dori



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

Re: File access from remote systems

[R.S.]

W dniu 2018-04-03 o 19:44, Ward, Mike S pisze:

Hello all, does anyone know of any software that allows access to VSAM, SEQ, 
CICS files from remote systems. I.E. distributed systems. How is the access 
done? Web service calls? MQ calls?


Remote z/OS ? ;-)))

Two free (built in) options:
* DFS/SMB - you z/OS is like Windows file server. Acceptable for read, 
poor for update.

* NFS - good for Unix/Linux and Windows.


BTW: It's very fine to show people how to open VSAM KSDS - just using 
notepad ;-)


--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: Software Delivery on Tape to be Discontinued

[R.S.]

W dniu 2018-04-04 o 17:34, Charles Mills pisze:

IBM sign the hash (in fact they sign whole serverpac)

I think the "whole serverpac" is effectively signed -- but the way that is done 
is to sign the hash. There are security advantages too long a digression for this reply.


If you really want to encrypt the content (ie. DVD files) then you have to make 
your pair of PRIVATE/PUBLIC keys. Yes, the customer has to do it and ask IBM to 
use his public key

Yep, that is the process that certificates and the TLS protocol automate. TLS 
does not do anything for you in terms of encryption that you could not do on 
your own -- but worst case doing it without TLS would require your sending a 
courier with a briefcase containing a secret key locked to his wrist to IBM, 
and IBM maintaining a secret key for each customer. TLS automates that process, 
securely.


NO!
Asymmetric crypto is the solution for secret key exchange. There is no 
longer need to exchange the keys using briefcase.
I keep my private key in secret and my public key is really public. You 
do the same with your key pair. Now I can encrypt (but NOT DECRYPT) some 
data using your public key and only private key holder can decrypt it 
(you). And vice versa - you can encrypt some data using my public key.
In case of doubt who is on the other end of wire (am I using YOUR key or 
someone else's key?)  certificates can be used.


Note: asymmetric cryptography is very cpu-consuming, approx. 1000 times 
more than symmetric. That's why people (protocols) tend to use 
asymmetric cyrpto to exchange small data portion - the key, symmetric 
one. After that both parties share their own, unique, disposable key for 
bulk data exchange.




--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: Software Delivery on Tape to be Discontinued

[Charles Mills]

> IBM sign the hash (in fact they sign whole serverpac)

I think the "whole serverpac" is effectively signed -- but the way that is done 
is to sign the hash. There are security advantages too long a digression for 
this reply.

> If you really want to encrypt the content (ie. DVD files) then you have to 
> make your pair of PRIVATE/PUBLIC keys. Yes, the customer has to do it and ask 
> IBM to use his public key

Yep, that is the process that certificates and the TLS protocol automate. TLS 
does not do anything for you in terms of encryption that you could not do on 
your own -- but worst case doing it without TLS would require your sending a 
courier with a briefcase containing a secret key locked to his wrist to IBM, 
and IBM maintaining a secret key for each customer. TLS automates that process, 
securely.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, April 4, 2018 7:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software Delivery on Tape to be Discontinued

W dniu 2018-04-04 o 02:58, Andrew Rowley pisze:
> On 4/04/2018 10:53 AM, Charles Mills wrote:
>> No, a digital signature does not require an authority.
>>
>> I publish my public key on my Web site.
>>
> How do I verify that the key that I see browsing your website is 
> really yours and hasn't been e.g. substituted in transit? Key exchange 
> is the hardest bit of cryptography.
>


It is simple.
ServerPac content is something non-secret - we don't want to encrypt it, we 
only want to be sure it is not altered by bad guys. (Let's assume it for a 
while)

So, we checksum he content using SHA. Everybody can check it is not tampered by 
repeating cheksum and comparing hash values with ...with WHAT?
Hash values can also be modified!
Of course IBM could pay for TV and newspaper commercial advertisement 
containing those values, but it is not practical way. ;-) However such way 
shows one of possible solutions: to deliver checksums using alternate way.
The other method could be to SIGN the hash value. Sign is a method from 
assymetric cryptography family. IBM sign the hash (in fact they sign whole 
serverpac) using it's PRIVATE key, which is the deepest secret of IBM, however 
*everybody* (including bad guys) can obtain PUBLIC key from  IBM and the public 
key plus method allows everybody to confirm (or
deny) this information was signed by IBM.

Note, the content is still not encrypted.
Is it possible to encypt it? For SSL/TLS download , it is unnecessary, because 
whole transmission is encrypted (and hard to break despite gossips).
If you really want to encrypt the content (ie. DVD files) then you have to make 
your pair of PRIVATE/PUBLIC keys. Yes, the customer has to do it and ask IBM to 
use his public key.  A little bit complex - IBM would have to collect and 
maintain keys from every customer. Each customer should take care about the 
keys again disclosure and ...lost. Keys should be replaced periodically, etc.  
IMHO much to much trouble for such content.

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

Re: Explanation about the SVCASF bit ("SVC can be assisted") in the SVC table?

[Rob Scott]

"SVC Assist" is a facility that performed some common housekeeping operations 
on behalf of the SVC - for example,  copying the information
stored at the last SVC interruption into the current request block, saving 
general registers, and loading the general registers with appropriate values.

It was implemented by opcode x'E503'.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dori Polotsky
Sent: Wednesday, April 4, 2018 10:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Explanation about the SVCASF bit ("SVC can be assisted") in the SVC 
table?

Hello,

Does anyone know the meaning of the SVCASF bit (x'01') of the SVCTP byte of the 
SVC table?

If I am not mistaken, on our system (z/OS 2.2 ADCD) following the IPL this bit 
is off for all SVC's except SVC 13 (ABEND, IEAVTRT2) and SVC 26 (LOCATE / 
CATALOG, IGG026DU).  Also, I did not see an option to select the value for this 
bit with SVCUPDTE.

Any insights would be appreciated.

Thank you very much,
  Dori

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

Re: Software Delivery on Tape to be Discontinued

[R.S.]

W dniu 2018-04-04 o 02:58, Andrew Rowley pisze:

On 4/04/2018 10:53 AM, Charles Mills wrote:

No, a digital signature does not require an authority.

I publish my public key on my Web site.

How do I verify that the key that I see browsing your website is 
really yours and hasn't been e.g. substituted in transit? Key exchange 
is the hardest bit of cryptography.





It is simple.
ServerPac content is something non-secret - we don't want to encrypt it, 
we only want to be sure it is not altered by bad guys. (Let's assume it 
for a while)


So, we checksum he content using SHA. Everybody can check it is not 
tampered by repeating cheksum and comparing hash values with ...with WHAT?

Hash values can also be modified!
Of course IBM could pay for TV and newspaper commercial advertisement 
containing those values, but it is not practical way. ;-)
However such way shows one of possible solutions: to deliver checksums 
using alternate way.
The other method could be to SIGN the hash value. Sign is a method from 
assymetric cryptography family. IBM sign the hash (in fact they sign 
whole serverpac) using it's PRIVATE key, which is the deepest secret of 
IBM, however *everybody* (including bad guys) can obtain PUBLIC key 
from  IBM and the public key plus method allows everybody to confirm (or 
deny) this information was signed by IBM.


Note, the content is still not encrypted.
Is it possible to encypt it? For SSL/TLS download , it is unnecessary, 
because whole transmission is encrypted (and hard to break despite 
gossips).
If you really want to encrypt the content (ie. DVD files) then you have 
to make your pair of PRIVATE/PUBLIC keys. Yes, the customer has to do it 
and ask IBM to use his public key.  A little bit complex - IBM would 
have to collect and maintain keys from every customer. Each customer 
should take care about the keys again disclosure and ...lost. Keys 
should be replaced periodically, etc.  IMHO much to much trouble for 
such content.




--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: Zconnect

[Sasso, Len]

I'm sorry, but I meant accessing, via a REST API, an external Website and 
downloading a file from the external site?


Thank You,
Len Sasso
System Administrator
Out-Of-The-Office:
TEAM: Together Everyone Achieves More

RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
t: +1.518.257.4209 | m: +1.518.894.0879
len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn
CSRA
Think Next. Now.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Wednesday, April 04, 2018 9:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Zconnect

Sasso, Len wrote:
> Does it include the ability to access and download a file from a REST API 
> site?
>

Yes.  You can find it, read it, and write it, in fact (and much more).

Please see Table 273 on PDF p. 508 in IBM z/OS Management Facility
Programming Guide, here, for a list of what you can do with the z/OSMF
data set and file REST API:

https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sc278420/$file/izua700_v2r3.pdf

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

This electronic message transmission contains information from CSRA that may be 
attorney-client privileged, proprietary or confidential. The information in 
this message is intended only for use by the individual(s) to whom it is 
addressed. If you believe you have received this message in error, please 
contact me immediately and be aware that any use, disclosure, copying or 
distribution of the contents of this message is strictly prohibited. NOTE: 
Regardless of content, this email shall not operate to bind CSRA to any order 
or other contract unless pursuant to explicit written agreement or government 
initiative expressly permitting the use of email for such purpose.

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

Re: Software Delivery on Tape to be Discontinued

[Charles Mills]

Thanks, @Alan, I missed @Andrew's question  (or rather, my SPAM filter missed 
it for me).

Alan's answer is unquestionably the correct one -- and also, I think in the 
earliest days of digital signatures, before the use of SSL/TLS browsing was 
widespread, the idea was that my public key was "public knowledge." You might 
have looked it up a month ago, you could look it up again today, your 
colleagues looked it up, it might be published in multiple places -- so any 
change introduced by MitM would be noticed. Not as good an answer as Alan's, 
but I think it was the original answer.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Alan Altmark
Sent: Wednesday, April 4, 2018 6:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software Delivery on Tape to be Discontinued

On Wed, 4 Apr 2018 10:58:16 +1000, Andrew Rowley  
wrote:
>How do I verify that the key that I see browsing your website is really 
>yours and hasn't been e.g. substituted in transit? Key exchange is the 
>hardest bit of cryptography.

Because you accessed the web site via https://, causing the transmission of the 
key to be encrypted and tamper-proof.  Further, Charles' web site uses a 
certificate published by a Certificate Authority that YOU trust.  Or more 
precisely, he uses a CA that the vendor of your browser trusts.  You trust your 
vendor implicitly by using their browser.

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

Re: Zconnect

[John Eells]

Sasso, Len wrote:

Does it include the ability to access and download a file from a REST API site?



Yes.  You can find it, read it, and write it, in fact (and much more).

Please see Table 273 on PDF p. 508 in IBM z/OS Management Facility
Programming Guide, here, for a list of what you can do with the z/OSMF 
data set and file REST API:


https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sc278420/$file/izua700_v2r3.pdf

--
John Eells
IBM Poughkeepsie
ee...@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: Zconnect

[Sasso, Len]

Does it include the ability to access and download a file from a REST API site?


Thank You,
Len Sasso
System Administrator
Out-Of-The-Office:
TEAM: Together Everyone Achieves More

RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
t: +1.518.257.4209 | m: +1.518.894.0879
len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn
CSRA
Think Next. Now.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Wednesday, April 04, 2018 7:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Zconnect

Timothy Sipples wrote:
> I probably should have also mentioned that z/OS Management Facility
> (z/OSMF) provides REST APIs for such tasks as provisioning services,
> submitting jobs, console interface services, and much more. z/OSMF is a no
> additional charge feature in the base z/OS operating system, and it's now
> (in z/OS 2.3) started automatically at IPL. More details are available here
> (z/OS 2.3 link):


Just so nobody tries to order z/OSMF...

z/OSMF is a base element of z/OS starting with z/OS V2.2, not an
orderable feature.  You will (or did) get it as part of z/OS itself.

Before z/OS V2.2, z/OSMF was a separate priced product with a price of
zero dollars per value unit and the same price for support.  ("Priced"
at zero dollars/pounds/yen/euros, etc.?  Yup.  You can't make some
things up, but that's how our systems work.)

As Timothy says, it has a variety of REST APIs.  One he didn't mention
is the file and data set API that some might find useful.  Also these
APIs are pretty rich, functionally.  For example, the jobs API lets you
submit jobs, check their status, and retrieve their output--all from a
browser-based application if you'd like.  We also added Cloud
Provisioning support during z/OS V2.2 so you can set up templates that
allow authorized people (like application developers) to instantiate and
tear down their own CICS AORs, DB2 data bases, MQ connections, and such.

It's worth mentioning that we added e-mail notifications from JCL on
JES2 systems in z/OS V2.3.  (I always threatened to put the z/OSMF
architect's e-mail address in the examples.)

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

This electronic message transmission contains information from CSRA that may be 
attorney-client privileged, proprietary or confidential. The information in 
this message is intended only for use by the individual(s) to whom it is 
addressed. If you believe you have received this message in error, please 
contact me immediately and be aware that any use, disclosure, copying or 
distribution of the contents of this message is strictly prohibited. NOTE: 
Regardless of content, this email shall not operate to bind CSRA to any order 
or other contract unless pursuant to explicit written agreement or government 
initiative expressly permitting the use of email for such purpose.

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

Re: Software Delivery on Tape to be Discontinued

[Alan Altmark]

On Wed, 4 Apr 2018 10:58:16 +1000, Andrew Rowley  
wrote:
>How do I verify that the key that I see browsing your website is really
>yours and hasn't been e.g. substituted in transit? Key exchange is the
>hardest bit of cryptography.

Because you accessed the web site via https://, causing the transmission of the 
key to be encrypted and tamper-proof.  Further, Charles' web site uses a 
certificate published by a Certificate Authority that YOU trust.  Or more 
precisely, he uses a CA that the vendor of your browser trusts.  You trust your 
vendor implicitly by using their browser.

THAT is what CA/Browser Forum (CAB) industry group is all about.

Alan Altmark
IBM

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

Re: Mini recovery system build

[Lou Losee]

http://mzelden.com/mvsutilr.html#jobs

Lou

--
Artificial Intelligence is no match for Natural Stupidity
  - Unknown

On Wed, Apr 4, 2018 at 7:20 AM, Tony Thigpen  wrote:

> I have been tasked with bringing our mini recovery system to a more
> current level. It's 'way back there', it's actually pre-z/OS.
>
> Our current production system is z/OS 1.13.
>
> Can anybody point me to a power-point or other document that I can use as
> a guide for this process?
>
> --
> Tony Thigpen
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Mini recovery system build

[W Mainframe]

Tony,
I believe Mark Zelden website has lot of scripts for building mini systems.
Dan


Sent from Yahoo Mail for iPhone


On Wednesday, April 4, 2018, 9:20 AM, Tony Thigpen  wrote:

I have been tasked with bringing our mini recovery system to a more 
current level. It's 'way back there', it's actually pre-z/OS.

Our current production system is z/OS 1.13.

Can anybody point me to a power-point or other document that I can use 
as a guide for this process?

-- 
Tony Thigpen

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




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

Mini recovery system build

[Tony Thigpen]

I have been tasked with bringing our mini recovery system to a more 
current level. It's 'way back there', it's actually pre-z/OS.


Our current production system is z/OS 1.13.

Can anybody point me to a power-point or other document that I can use 
as a guide for this process?


--
Tony Thigpen

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

Re: Zconnect

[John Eells]

Timothy Sipples wrote:

I probably should have also mentioned that z/OS Management Facility
(z/OSMF) provides REST APIs for such tasks as provisioning services,
submitting jobs, console interface services, and much more. z/OSMF is a no
additional charge feature in the base z/OS operating system, and it's now
(in z/OS 2.3) started automatically at IPL. More details are available here
(z/OS 2.3 link):



Just so nobody tries to order z/OSMF...

z/OSMF is a base element of z/OS starting with z/OS V2.2, not an 
orderable feature.  You will (or did) get it as part of z/OS itself.


Before z/OS V2.2, z/OSMF was a separate priced product with a price of 
zero dollars per value unit and the same price for support.  ("Priced" 
at zero dollars/pounds/yen/euros, etc.?  Yup.  You can't make some 
things up, but that's how our systems work.)


As Timothy says, it has a variety of REST APIs.  One he didn't mention 
is the file and data set API that some might find useful.  Also these 
APIs are pretty rich, functionally.  For example, the jobs API lets you 
submit jobs, check their status, and retrieve their output--all from a 
browser-based application if you'd like.  We also added Cloud 
Provisioning support during z/OS V2.2 so you can set up templates that 
allow authorized people (like application developers) to instantiate and 
tear down their own CICS AORs, DB2 data bases, MQ connections, and such.


It's worth mentioning that we added e-mail notifications from JCL on 
JES2 systems in z/OS V2.3.  (I always threatened to put the z/OSMF 
architect's e-mail address in the examples.)


--
John Eells
IBM Poughkeepsie
ee...@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: Software Delivery on Tape to be Discontinued

[John Eells]

Andrew Rowley wrote:

On 3/04/2018 9:21 PM, John Eells wrote:


If you have a requirement for packages signed with strong algorithms,
please open an RFE.


Is the SMP/E package signed, or just checksummed? A stronger hash is no
real value if the hash itself can be substituted because it is not
cryptographically signed.


They are not signed today.

The point of my wording was that, if we do sign them eventually, we 
probably shouldn't sign them using SHA-1 or something equally weak.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Explanation about the SVCASF bit ("SVC can be assisted") in the SVC table?

[Dori Polotsky]

Hello,

Does anyone know the meaning of the SVCASF bit (x'01') of the SVCTP byte of
the SVC table?

If I am not mistaken, on our system (z/OS 2.2 ADCD) following the IPL this
bit is off for all SVC's except SVC 13 (ABEND, IEAVTRT2) and SVC 26 (LOCATE
/ CATALOG, IGG026DU).  Also, I did not see an option to select the value
for this bit with SVCUPDTE.

Any insights would be appreciated.

Thank you very much,
  Dori

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