Re: DB2 and RACF entities

[Itschak Mugzach]

There might be other db2 configuration tables that hold identities such as
IPNAMES.

ITschak

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Thu, Jun 16, 2022 at 8:09 AM Áron Kalapos  wrote:

> SYSIBM.SYS*AUTH tables hold all GRANTs currently in effect. Maybe if you
> have a periodic IC setup and a relatively recent IC, you could take a look
> at the list of users in that RACF group and compare to GRANTs?
>
> - QG
>
> Horacio Luis Villa  ezt írta (időpont:
> 2022. jún. 16., Cs, 1:35):
>
> > You should query Sysibm.Sysuserauth
> > 
> > De: IBM Mainframe Discussion List  en nombre
> de
> > Bob Bridges 
> > Enviado: miércoles, 15 de junio de 2022 20:14
> > Para: IBM-MAIN@LISTSERV.UA.EDU 
> > Asunto: [EXTERNAL] Re: DB2 and RACF entities
> >
> > I used to be a member of the DB2 listserv - maybe I still am - but they
> > fell silent a while ago and I quit expecting it to change.  But yeah, you
> > should be able to find out from a DBA.
> >
> > As I tried to say in the last post (but I don't think I was very clear),
> > DB2 saves all its GRANTs in a table, or maybe in more than one table.
> You
> > should be able to write a query to look at that table (if you have the
> > right authorization) for any GRANTs for the ID that is the group you
> > deleted and restored - or, of course, any other GRANTs that interest you.
> > You just have to find out the name of the table(s), which would be some
> > standard documented table name.  If I run across it I'll let you know,
> but
> > I'm sure it'll be in the DB2 documentation.
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* We must picture Hell as a state where everyone is perpetually
> concerned
> > about his own dignity and advancement, where everyone has a grievance,
> and
> > where eveyone lives the deadly serious passions of envy, self-importance,
> > and resentment.  -C S Lewis, preface to _The Screwtape Letters_ */
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Radoslaw Skorupka
> > Sent: Wednesday, June 15, 2022 16:59
> >
> > It's the opposite: I deleted the group from RACF and some job failed.
> > I quickly re-created the group and connect and restarted job ended OK.
> > However I want to check out what GRANT or other was issued against the
> > group. Or more generally - I want to find out the groupname in DB2
> catalog.
> > Not for this group, but for other groups and environments.
> > Yeah, I should ask DB2 admin...  ;-)
> >
> > --- W dniu 13.06.2022 o 23:07, Bob Bridges pisze:
> > > RACF doesn't know, so once you've deleted the GRANT from DB2 I don’t
> > know of a way to find out what you lost (unless you can get it from a
> > backup).  But there are tables in DB2 that list all GRANTs, so you can
> > export those to, say, Excel and do some sorting and other munging to get
> a
> > sensible list.  It's been a while, but I did that as part of a project to
> > convert DB2 security to RACF.
> > >
> > > When I say "it's been a while", what I mean is that I don't remember
> > what that table or those tables were called.  But I was able to find them
> > back then, so I'm sure it's documented in DB2 somewhere.
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > Behalf Of Radoslaw Skorupka
> > > Sent: Monday, June 13, 2022 16:09
> > >
> > > The following scenario: DB2 v12 using pre-RACF (GRANT/REVOKE) security.
> > Of course userids and groupids are taken from RACF. There are several
> > groups which are candidates to delete as they look as not needed. However
> > some of them have DB2 GRANTs, so those groups should not be deleted.
> > >
> > > So far, so good. Unfortunately some group was deleted, despite it was
> > used by DB2. I don't know details, but AFAIK probably it was something
> > related to SET SQL ID or so.
> > >
> > > Q: is there any method to find out *all* RACF users and groups used for
> > any authorisation in DB2?
> >
> > --
> > 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 

Re: SFTP JOB Data parameter

[Bill Godfrey]

My mistake about OGET, it does have the "-".

On Thu, 16 Jun 2022 00:15:23 -0500, Bill Godfrey wrote:

>Your first "echo" doesn't have a "+" at the end like your original did.
>
>Your "OGET" doesn't have a "-" at the end like your original did.
>
>The  symbol generates a 2-digit year, but your filenames use a 4-digit 
>year.
>Instead of  use 
>
>On Thu, 16 Jun 2022 07:45:53 +0300, saurabh khandelwal wrote:
>
>>
>>Now I am getting below error, while running this JCL code.
>>
>>
>>
>>JCL
>>
>>
>>
>>//SFTPSEBC JOB (7330),MSGCLASS=X,CLASS=P,NOTIFY=
>>
>>//TAILOR  EXEC PGM=PGM=EZACFSM1
>>
>>//SYSOUT   DD   DISP=(NEW,PASS,DELETE),DSN=,
>>
>>// UNIT=VIO,SPACE=(TRK,(1))
>>
>>//SYSINDD *
>>
>>OSHELL { echo 'lcd /u/op117/';
>>
>>  echo 'cd /FRB/EBCClearing/Staging/tmp';+
>>
>>  echo 'ASCII'; +
>>
>>  echo 'get EBC-GOV-'; } | +
>>
>>sftp -P  eftmfge...@10.222.xx.xx
>>
>>OGET '/u/op117/EBC-GOV-'  -
>>
>>  'NBFDP.DATA.XX.XX.SFTP'
>>
>>//STEP1   EXEC PGM=IKJEFT01,REGION=0M
>>
>>//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC
>>
>>//SYSTSIN   DD DSN=,DISP=(OLD,DELETE)
>>
>>//OUTPUT DD SYSOUT=*
>>
>>//SYSTSPRT DD SYSOUT=*
>>
>>/*
>>
>>
>>
>>Output below :
>>
>>
>>
>>READY
>>
>>OSHELL { echo 'lcd
>>/u/op117/';
>>
>> OSHELL RC =  256
>>
>>
>>
>>
>> OSHELL Exit Status =
>>1
>>
>>
>>
>>READY
>>
>>  echo 'cd /FRB/EBCClearing/Staging/tmp';  echo 'ASCII'; echo 'get
>>EBC
>>
>>.22.10
>>
>>COMMAND ECHO NOT
>>FOUND
>>
>>READY
>>
>>OGET '/u/op117/EBC-GOV-220616.txt'
>>'NBFDP.DATA.XX.
>>
>>RETURN CODE 0081, REASON CODE 05620062.  AN ERROR OCCURRED DURING THE
>>OPENIN
>>
>>READY
>>
>>END
>>
>>
>>
>>
>>
>>FSUM7332 syntax error: got EOF, expecting }
>>
>>On Wed, Jun 15, 2022, 21:45 Farley, Peter x23353 <
>>031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>>
>>> Thanks again Sri.  After reading those posts, I do see the issue.  That
>>> would be the "Don't break existing jobs" mantra.
>>>
>>> I would instead have said "Go ahead and break them in QA so we can fix the
>>> broken ones", but I don't pay the bills and "breaking them in QA" AssUMes
>>> that QA batch initiator classes are distinct from Production batch
>>> initiator classes, which isn't true at any large shop where I have worked.
>>>
>>> But I agree with Gil's final post in that thread - it should have been
>>> implemented as a new JCL option (similar to EXPORT SYMLIST) rather than an
>>> initiator class parameter.  Positive opt-in for jobs that want to use it,
>>> leave the others alone.  Perhaps a global parameter for the JCL interpreter
>>> to allow or disallow the new JCL option during the initial transition so
>>> shops could choose to allow or disallow use of the new JCL option to
>>> prevent accidental breakage by too-eager programmers until automated SDLC
>>> rules for JCL are updated and enforced.
>>>
>>> Water under the proverbial bridge now.  At least we have EZACFSM1 as an
>>> alternative, so that's good.
>>>
>>> Peter
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List  On Behalf
>>> Of Sri h Kolusu
>>> Sent: Wednesday, June 15, 2022 1:32 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: SFTP JOB Data parameter
>>>
>>> >>> But that raises the question why NOT always allow system symbols in
>>> >>> every batch initiator?  Allowing them just seems like a no-brainer
>>> >>> to me
>>>
>>> Peter,
>>>
>>> There have been several discussions on IBM-MAIN about SYSSYM=ALLOW and
>>> here is a post which explains one of the reason.
>>>
>>> https://www.mail-archive.com/ibm-main@listserv.ua.edu/msg62638.html
>>>
>>> Thanks,
>>> Kolusu
>>> --
>>>
>>> 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: SFTP JOB Data parameter

[Bill Godfrey]

Your first "echo" doesn't have a "+" at the end like your original did.

Your "OGET" doesn't have a "-" at the end like your original did.

The  symbol generates a 2-digit year, but your filenames use a 4-digit 
year.
Instead of  use 

On Thu, 16 Jun 2022 07:45:53 +0300, saurabh khandelwal wrote:

>
>Now I am getting below error, while running this JCL code.
>
>
>
>JCL
>
>
>
>//SFTPSEBC JOB (7330),MSGCLASS=X,CLASS=P,NOTIFY=
>
>//TAILOR  EXEC PGM=PGM=EZACFSM1
>
>//SYSOUT   DD   DISP=(NEW,PASS,DELETE),DSN=,
>
>// UNIT=VIO,SPACE=(TRK,(1))
>
>//SYSINDD *
>
>OSHELL { echo 'lcd /u/op117/';
>
>  echo 'cd /FRB/EBCClearing/Staging/tmp';+
>
>  echo 'ASCII'; +
>
>  echo 'get EBC-GOV-'; } | +
>
>sftp -P  eftmfge...@10.222.xx.xx
>
>OGET '/u/op117/EBC-GOV-'  -
>
>  'NBFDP.DATA.XX.XX.SFTP'
>
>//STEP1   EXEC PGM=IKJEFT01,REGION=0M
>
>//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC
>
>//SYSTSIN   DD DSN=,DISP=(OLD,DELETE)
>
>//OUTPUT DD SYSOUT=*
>
>//SYSTSPRT DD SYSOUT=*
>
>/*
>
>
>
>Output below :
>
>
>
>READY
>
>OSHELL { echo 'lcd
>/u/op117/';
>
> OSHELL RC =  256
>
>
>
>
> OSHELL Exit Status =
>1
>
>
>
>READY
>
>  echo 'cd /FRB/EBCClearing/Staging/tmp';  echo 'ASCII'; echo 'get
>EBC
>
>.22.10
>
>COMMAND ECHO NOT
>FOUND
>
>READY
>
>OGET '/u/op117/EBC-GOV-220616.txt'
>'NBFDP.DATA.XX.
>
>RETURN CODE 0081, REASON CODE 05620062.  AN ERROR OCCURRED DURING THE
>OPENIN
>
>READY
>
>END
>
>
>
>
>
>FSUM7332 syntax error: got EOF, expecting }
>
>On Wed, Jun 15, 2022, 21:45 Farley, Peter x23353 <
>031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Thanks again Sri.  After reading those posts, I do see the issue.  That
>> would be the "Don't break existing jobs" mantra.
>>
>> I would instead have said "Go ahead and break them in QA so we can fix the
>> broken ones", but I don't pay the bills and "breaking them in QA" AssUMes
>> that QA batch initiator classes are distinct from Production batch
>> initiator classes, which isn't true at any large shop where I have worked.
>>
>> But I agree with Gil's final post in that thread - it should have been
>> implemented as a new JCL option (similar to EXPORT SYMLIST) rather than an
>> initiator class parameter.  Positive opt-in for jobs that want to use it,
>> leave the others alone.  Perhaps a global parameter for the JCL interpreter
>> to allow or disallow the new JCL option during the initial transition so
>> shops could choose to allow or disallow use of the new JCL option to
>> prevent accidental breakage by too-eager programmers until automated SDLC
>> rules for JCL are updated and enforced.
>>
>> Water under the proverbial bridge now.  At least we have EZACFSM1 as an
>> alternative, so that's good.
>>
>> Peter
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf
>> Of Sri h Kolusu
>> Sent: Wednesday, June 15, 2022 1:32 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: SFTP JOB Data parameter
>>
>> >>> But that raises the question why NOT always allow system symbols in
>> >>> every batch initiator?  Allowing them just seems like a no-brainer
>> >>> to me
>>
>> Peter,
>>
>> There have been several discussions on IBM-MAIN about SYSSYM=ALLOW and
>> here is a post which explains one of the reason.
>>
>> https://www.mail-archive.com/ibm-main@listserv.ua.edu/msg62638.html
>>
>> Thanks,
>> Kolusu
>> --
>>
>> 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: DB2 and RACF entities

[Áron Kalapos]

SYSIBM.SYS*AUTH tables hold all GRANTs currently in effect. Maybe if you
have a periodic IC setup and a relatively recent IC, you could take a look
at the list of users in that RACF group and compare to GRANTs?

- QG

Horacio Luis Villa  ezt írta (időpont:
2022. jún. 16., Cs, 1:35):

> You should query Sysibm.Sysuserauth
> 
> De: IBM Mainframe Discussion List  en nombre de
> Bob Bridges 
> Enviado: miércoles, 15 de junio de 2022 20:14
> Para: IBM-MAIN@LISTSERV.UA.EDU 
> Asunto: [EXTERNAL] Re: DB2 and RACF entities
>
> I used to be a member of the DB2 listserv - maybe I still am - but they
> fell silent a while ago and I quit expecting it to change.  But yeah, you
> should be able to find out from a DBA.
>
> As I tried to say in the last post (but I don't think I was very clear),
> DB2 saves all its GRANTs in a table, or maybe in more than one table.  You
> should be able to write a query to look at that table (if you have the
> right authorization) for any GRANTs for the ID that is the group you
> deleted and restored - or, of course, any other GRANTs that interest you.
> You just have to find out the name of the table(s), which would be some
> standard documented table name.  If I run across it I'll let you know, but
> I'm sure it'll be in the DB2 documentation.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* We must picture Hell as a state where everyone is perpetually concerned
> about his own dignity and advancement, where everyone has a grievance, and
> where eveyone lives the deadly serious passions of envy, self-importance,
> and resentment.  -C S Lewis, preface to _The Screwtape Letters_ */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Radoslaw Skorupka
> Sent: Wednesday, June 15, 2022 16:59
>
> It's the opposite: I deleted the group from RACF and some job failed.
> I quickly re-created the group and connect and restarted job ended OK.
> However I want to check out what GRANT or other was issued against the
> group. Or more generally - I want to find out the groupname in DB2 catalog.
> Not for this group, but for other groups and environments.
> Yeah, I should ask DB2 admin...  ;-)
>
> --- W dniu 13.06.2022 o 23:07, Bob Bridges pisze:
> > RACF doesn't know, so once you've deleted the GRANT from DB2 I don’t
> know of a way to find out what you lost (unless you can get it from a
> backup).  But there are tables in DB2 that list all GRANTs, so you can
> export those to, say, Excel and do some sorting and other munging to get a
> sensible list.  It's been a while, but I did that as part of a project to
> convert DB2 security to RACF.
> >
> > When I say "it's been a while", what I mean is that I don't remember
> what that table or those tables were called.  But I was able to find them
> back then, so I'm sure it's documented in DB2 somewhere.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of Radoslaw Skorupka
> > Sent: Monday, June 13, 2022 16:09
> >
> > The following scenario: DB2 v12 using pre-RACF (GRANT/REVOKE) security.
> Of course userids and groupids are taken from RACF. There are several
> groups which are candidates to delete as they look as not needed. However
> some of them have DB2 GRANTs, so those groups should not be deleted.
> >
> > So far, so good. Unfortunately some group was deleted, despite it was
> used by DB2. I don't know details, but AFAIK probably it was something
> related to SET SQL ID or so.
> >
> > Q: is there any method to find out *all* RACF users and groups used for
> any authorisation in DB2?
>
> --
> 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: IBM Semeru Runtime 11.0.15.0 for z/OS Now Available

[Timothy Sipples]

Darrold Usher wrote:
> Is there a Semeru Program product support website where I
>can track developments?

Yes, IBM is keeping the "What's new" section of the Semeru documentation up to 
date from what I can see. Here's the direct link (subject to change):

https://www.ibm.com/docs/en/semeru-runtime-ce-z/11?topic=guide-whats-new

I recommend subscribing to IBM Support notifications for the "Semeru Runtimes 
for z/OS" and "IBM Semeru Runtime Certified Edition for z/OS" products. You can 
also subscribe to the general "IBM Semeru Runtimes" product notices if you 
like. You can do all that here:

https://www.ibm.com/support/mynotifications

The general IBM Semeru Runtimes (all platforms) landing page is here:

https://developer.ibm.com/languages/java/semeru-runtimes/

— — — — —
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM zSystems/LinuxONE, Asia-Pacific
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: SFTP JOB Data parameter

[saurabh khandelwal]

Dear,



Now I am getting below error, while running this JCL code.



JCL



//SFTPSEBC JOB (7330),MSGCLASS=X,CLASS=P,NOTIFY=

//TAILOR  EXEC PGM=PGM=EZACFSM1

//SYSOUT   DD   DISP=(NEW,PASS,DELETE),DSN=,

// UNIT=VIO,SPACE=(TRK,(1))

//SYSINDD *

OSHELL { echo 'lcd /u/op117/';

  echo 'cd /FRB/EBCClearing/Staging/tmp';+

  echo 'ASCII'; +

  echo 'get EBC-GOV-'; } | +

sftp -P  eftmfge...@10.222.xx.xx

OGET '/u/op117/EBC-GOV-'  -

  'NBFDP.DATA.XX.XX.SFTP'

//STEP1   EXEC PGM=IKJEFT01,REGION=0M

//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC

//SYSTSIN   DD DSN=,DISP=(OLD,DELETE)

//OUTPUT DD SYSOUT=*

//SYSTSPRT DD SYSOUT=*

/*



Output below :



READY

OSHELL { echo 'lcd
/u/op117/';

 OSHELL RC =  256




 OSHELL Exit Status =
1



READY

  echo 'cd /FRB/EBCClearing/Staging/tmp';  echo 'ASCII'; echo 'get
EBC

.22.10

COMMAND ECHO NOT
FOUND

READY

OGET '/u/op117/EBC-GOV-220616.txt'
'NBFDP.DATA.XX.

RETURN CODE 0081, REASON CODE 05620062.  AN ERROR OCCURRED DURING THE
OPENIN

READY

END





FSUM7332 syntax error: got EOF, expecting }

On Wed, Jun 15, 2022, 21:45 Farley, Peter x23353 <
031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> Thanks again Sri.  After reading those posts, I do see the issue.  That
> would be the "Don't break existing jobs" mantra.
>
> I would instead have said "Go ahead and break them in QA so we can fix the
> broken ones", but I don't pay the bills and "breaking them in QA" AssUMes
> that QA batch initiator classes are distinct from Production batch
> initiator classes, which isn't true at any large shop where I have worked.
>
> But I agree with Gil's final post in that thread - it should have been
> implemented as a new JCL option (similar to EXPORT SYMLIST) rather than an
> initiator class parameter.  Positive opt-in for jobs that want to use it,
> leave the others alone.  Perhaps a global parameter for the JCL interpreter
> to allow or disallow the new JCL option during the initial transition so
> shops could choose to allow or disallow use of the new JCL option to
> prevent accidental breakage by too-eager programmers until automated SDLC
> rules for JCL are updated and enforced.
>
> Water under the proverbial bridge now.  At least we have EZACFSM1 as an
> alternative, so that's good.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Sri h Kolusu
> Sent: Wednesday, June 15, 2022 1:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SFTP JOB Data parameter
>
> >>> But that raises the question why NOT always allow system symbols in
> >>> every batch initiator?  Allowing them just seems like a no-brainer
> >>> to me
>
> Peter,
>
> There have been several discussions on IBM-MAIN about SYSSYM=ALLOW and
> here is a post which explains one of the reason.
>
> https://www.mail-archive.com/ibm-main@listserv.ua.edu/msg62638.html
>
> Thanks,
> Kolusu
> --
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: RIsks of sharing FICON adapters between LPARs on the same host

[Timothy Sipples]

You can and should *cryptographically* isolate z/OS data sets using z/OS Data 
Set Encryption, preferably with protected key cryptography if available. You 
can find out more about this feature (and how to implement it) here:

https://www.ibm.com/docs/en/zos/2.5.0?topic=sets-data-set-encryption
https://www.redbooks.ibm.com/abstracts/sg248410.html

With z/OS Data Set Encryption any/all encrypted data sets are encrypted before 
I/O. By the time the data (inside the encrypted data sets) reach the FICON 
Express adapters they're already encrypted. These cryptographic 
separation/isolation boundaries are per individual data set if desired, so 
they're highly granular.

Whereupon you can ask *them* why they aren't encrypting all (or most) 
individual files with separate keys (if/as merited), and/or why they're using 
clear key encryption. :-)

— — — — —
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM zSystems/LinuxONE, Asia-Pacific
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: DB2 and RACF entities

[Horacio Luis Villa]

You should query Sysibm.Sysuserauth

De: IBM Mainframe Discussion List  en nombre de Bob 
Bridges 
Enviado: miércoles, 15 de junio de 2022 20:14
Para: IBM-MAIN@LISTSERV.UA.EDU 
Asunto: [EXTERNAL] Re: DB2 and RACF entities

I used to be a member of the DB2 listserv - maybe I still am - but they fell 
silent a while ago and I quit expecting it to change.  But yeah, you should be 
able to find out from a DBA.

As I tried to say in the last post (but I don't think I was very clear), DB2 
saves all its GRANTs in a table, or maybe in more than one table.  You should 
be able to write a query to look at that table (if you have the right 
authorization) for any GRANTs for the ID that is the group you deleted and 
restored - or, of course, any other GRANTs that interest you.  You just have to 
find out the name of the table(s), which would be some standard documented 
table name.  If I run across it I'll let you know, but I'm sure it'll be in the 
DB2 documentation.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* We must picture Hell as a state where everyone is perpetually concerned 
about his own dignity and advancement, where everyone has a grievance, and 
where eveyone lives the deadly serious passions of envy, self-importance, and 
resentment.  -C S Lewis, preface to _The Screwtape Letters_ */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Wednesday, June 15, 2022 16:59

It's the opposite: I deleted the group from RACF and some job failed.
I quickly re-created the group and connect and restarted job ended OK.
However I want to check out what GRANT or other was issued against the group. 
Or more generally - I want to find out the groupname in DB2 catalog.
Not for this group, but for other groups and environments.
Yeah, I should ask DB2 admin...  ;-)

--- W dniu 13.06.2022 o 23:07, Bob Bridges pisze:
> RACF doesn't know, so once you've deleted the GRANT from DB2 I don’t know of 
> a way to find out what you lost (unless you can get it from a backup).  But 
> there are tables in DB2 that list all GRANTs, so you can export those to, 
> say, Excel and do some sorting and other munging to get a sensible list.  
> It's been a while, but I did that as part of a project to convert DB2 
> security to RACF.
>
> When I say "it's been a while", what I mean is that I don't remember what 
> that table or those tables were called.  But I was able to find them back 
> then, so I'm sure it's documented in DB2 somewhere.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Radoslaw Skorupka
> Sent: Monday, June 13, 2022 16:09
>
> The following scenario: DB2 v12 using pre-RACF (GRANT/REVOKE) security. Of 
> course userids and groupids are taken from RACF. There are several groups 
> which are candidates to delete as they look as not needed. However some of 
> them have DB2 GRANTs, so those groups should not be deleted.
>
> So far, so good. Unfortunately some group was deleted, despite it was used by 
> DB2. I don't know details, but AFAIK probably it was something related to SET 
> SQL ID or so.
>
> Q: is there any method to find out *all* RACF users and groups used for any 
> authorisation in DB2?

--
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: DB2 and RACF entities

[Bob Bridges]

I used to be a member of the DB2 listserv - maybe I still am - but they fell 
silent a while ago and I quit expecting it to change.  But yeah, you should be 
able to find out from a DBA.

As I tried to say in the last post (but I don't think I was very clear), DB2 
saves all its GRANTs in a table, or maybe in more than one table.  You should 
be able to write a query to look at that table (if you have the right 
authorization) for any GRANTs for the ID that is the group you deleted and 
restored - or, of course, any other GRANTs that interest you.  You just have to 
find out the name of the table(s), which would be some standard documented 
table name.  If I run across it I'll let you know, but I'm sure it'll be in the 
DB2 documentation.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* We must picture Hell as a state where everyone is perpetually concerned 
about his own dignity and advancement, where everyone has a grievance, and 
where eveyone lives the deadly serious passions of envy, self-importance, and 
resentment.  -C S Lewis, preface to _The Screwtape Letters_ */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Wednesday, June 15, 2022 16:59

It's the opposite: I deleted the group from RACF and some job failed.
I quickly re-created the group and connect and restarted job ended OK.
However I want to check out what GRANT or other was issued against the group. 
Or more generally - I want to find out the groupname in DB2 catalog.
Not for this group, but for other groups and environments.
Yeah, I should ask DB2 admin...  ;-)

--- W dniu 13.06.2022 o 23:07, Bob Bridges pisze:
> RACF doesn't know, so once you've deleted the GRANT from DB2 I don’t know of 
> a way to find out what you lost (unless you can get it from a backup).  But 
> there are tables in DB2 that list all GRANTs, so you can export those to, 
> say, Excel and do some sorting and other munging to get a sensible list.  
> It's been a while, but I did that as part of a project to convert DB2 
> security to RACF.
>
> When I say "it's been a while", what I mean is that I don't remember what 
> that table or those tables were called.  But I was able to find them back 
> then, so I'm sure it's documented in DB2 somewhere.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Radoslaw Skorupka
> Sent: Monday, June 13, 2022 16:09
>
> The following scenario: DB2 v12 using pre-RACF (GRANT/REVOKE) security. Of 
> course userids and groupids are taken from RACF. There are several groups 
> which are candidates to delete as they look as not needed. However some of 
> them have DB2 GRANTs, so those groups should not be deleted.
>
> So far, so good. Unfortunately some group was deleted, despite it was used by 
> DB2. I don't know details, but AFAIK probably it was something related to SET 
> SQL ID or so.
>
> Q: is there any method to find out *all* RACF users and groups used for any 
> authorisation in DB2?

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

Re: Rename Alias in a Load libary

[CM Poncelet]

AFAIK An LMOD may have up to 64 aliases. How to alias it via a usermod,
I don't remember. I guess it could be done via an ALIAS linkage editor
control card (before the NAME card) and then figure out what the usermod
should be from there.
 
Anyway, I attach some assembler code (ALIASPDS.TXT) that can alias any
member in a PDS, if that helps. Cheers.

On 15/06/2022 03:53, Paul Gilmartin wrote:
> On Tue, 14 Jun 2022 21:15:39 -0500, Mike Schwab  wrote:
>
>> Can't.  Create another alias.  Delete old alias name.
>>
> Does it make a difference?
>
> In fact, if the directory entries are kept in alphabetical order it doesn't
> work to overwrite the old name in place with a new name -- a new
> entry must be created in the correct position and other entries shuffled
> to fill the gap.
>
>> On Tue, Jun 14, 2022 at 2:04 PM Shelia Chalk wrote:
>>> Has anyone ever used a usermod to rename a alias in a lmod library?
>>> ERBSMFI   *ALIAS


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MEMBER NAME  ALIASPDS
*
* THIS PROGRAM ALIASES ENTRIES IN A PARTITIONED DATASET.
* MEMBERS MAY HAVE FIXED OR VARIABLE LOGICAL RECORD LENGTH (FB OR VB).
* MEMBER NAME AND ALIAS MUST BE SUPPLIED VIA SYSIN CARD.
*
*
* FORMAT OF SYSIN CARD IS
*   'MEMBER=@@...@,ALIAS=@@...@ '
* WHERE '@@...@' REPRESENTS A 1 TO 8 CHAR VALID MEMBER/ALIAS NAME
* AND WHERE ANYTHING (INCLUDING COMMENTS) (EXCEPT MEMBER= //  /*) MAY
* PRECEDE THE 'MEMBER=' START OF CARD DATA
* AND WHERE THE END OF CARD DATA (AFTER ALIAS NAME) MUST BE A BLANK.
* NOTE THAT THE COMMA, AFTER THE MEMBER NAME, IS MANDATORY,
* EACH SEPARATE ALIAS REQUEST MUST BE ON A SEPARATE CARD
* AND THE CARDS ARE FIXED RECL=80 WITH DATA IN COLS 1 TO 72 INCLUSIVE,
* DECLARED VIA DDNAME SYSIN.
*
* MEMBER NAMES MUST BE IN ASCENDING ALPHABETICAL ORDER.
*
* INVALID SYSIN CARDS ARE IGNORED.
*
* ALIASES SUCCESSFULLY ADDED ARE LISTED UNDER DDNAME=REPORTS OUTPUT.
*
* 05/06/15 CMP - ALLOW ANY MEMBER OR ALIAS NAME
* CREATED: CHRIS PONCELET12/10/88
*
***
*
 PRINT  ON,GEN
ALIASPDS CSECT START CONTROL SECTION
*
* PASSING  THE 'NEXT' LABEL AS A PARAMETER TO THE 'READREC' MACRO
*
***
** MACROS *
*
 EQUREGS 
 AGO   .SKIPIT
*
* THIS IS WHAT THE EQUREGS MACRO DEFINES:
* 
R0   EQU   0REDEFINE REGISTERS
R1   EQU   1
R2   EQU   2
R3   EQU   3
R4   EQU   4
R5   EQU   5
R6   EQU   6
R7   EQU   7
R8   EQU   8
R9   EQU   9
R10  EQU   10
R11  EQU   11
R12  EQU   12
R13  EQU   13
R14  EQU   14
R15  EQU   15
*
.SKIPIT  ANOP
*
 MACRO
   READREC 
   GET  READREC MACRO
 MVC   INPUT(80),0(R1) MOVE FROM BUFFER TO INPUT AREA
 MEND
*
 MACRO
   WRITEREC
   PUT   REPORTS,OUTPUT  WRITEREC MACRO
 MEND
*
*** END OF MACROS *
***
*
**
*** INITIAL PROCESSING ***
**
*
* NOTE: SAVE ALL REGISTERS ON ENTRY, AT 18 FULLWORDS STARTING AT
*   ADDRESS GIVEN IN R13 - USING STORE MULTIPLE.
*   THEN USE R14 (SAVED, THAT IS) TO RETURN CONTROL AFTER EXECUTION
*   OF THIS PROGRAM (AFTER RELOADING USING LOAD MULTIPLE.)
*
BEGINSTM   R14,R12,12(R13) SAVE REGISTERS 14->12 TO OFFSET 12
 BALR  R11,R0  LOAD CURRENT LOCATION INTO R11
 USING *,R11,R3DEFINE R11 + R3 AS BASE REGISTERS
NAMEOFT  EQU   NAME-*
TTROFT   EQU   TTR-*
ALIASOFT EQU   ALIAS-*
KOFT EQU   K-*
COFT EQU   C-*
INPUTOFT EQU   INPUT-*
 LAR3,*-4+4096
 STR13,SAVER13 FREE REGISTER 13 BY SAVING
 LAR13,SAVEBLK LOAD MY SAVEAREA'S ADDRESS INTO R13
*
***
 START OF PROGRAM CODE PROPER *
***
*
 OPEN  (SYSIN,(INPUT))
 L R4,=F'64'   FOR COUNTING ¬> 64 CARDS
 LRR9,R11  FOR INDEXING MEMBER NAMES + BASE
 LAR9,0(,R9)   CLEAR TOP 8 BITS
 S R9,=F'14'
 LRR10,R11 FOR INDEXING ALIAS NAMES + BASE
 LAR10,0(,R10) CLEAR TOP 8 BITS
 S R10,=F'8'
*
* DO UNTIL THERE ARE NO MORE SYSIN RECORDS
*
NEXT READREC SYSIN
  

Re: DB2 and RACF entities

[Radoslaw Skorupka]

It's the opposite: I deleted the group from RACF and some job failed.
I quickly re-created the group and connect and restarted job ended OK.
However I want to check out what GRANT or other was issued against the 
group. Or more generally - I want to find out the groupname in DB2 catalog.

Not for this group, but for other groups and environments.
Yeah, I should ask DB2 admin...  ;-)

--
Radoslaw Skorupka
Lodz, Poland



W dniu 13.06.2022 o 23:07, Bob Bridges pisze:

RACF doesn't know, so once you've deleted the GRANT from DB2 I don’t know of a 
way to find out what you lost (unless you can get it from a backup).  But there 
are tables in DB2 that list all GRANTs, so you can export those to, say, Excel 
and do some sorting and other munging to get a sensible list.  It's been a 
while, but I did that as part of a project to convert DB2 security to RACF.

When I say "it's been a while", what I mean is that I don't remember what that 
table or those tables were called.  But I was able to find them back then, so I'm sure 
it's documented in DB2 somewhere.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* If I try to be like him, who will be like me?  -Yiddish proverb */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Monday, June 13, 2022 16:09

The following scenario: DB2 v12 using pre-RACF (GRANT/REVOKE) security. Of 
course userids and groupids are taken from RACF. There are several groups which 
are candidates to delete as they look as not needed. However some of them have 
DB2 GRANTs, so those groups should not be deleted.

So far, so good. Unfortunately some group was deleted, despite it was used by 
DB2. I don't know details, but AFAIK probably it was something related to SET 
SQL ID or so.

Q: is there any method to find out *all* RACF users and groups used for any 
authorisation in DB2?


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

Re: SFTP JOB Data parameter

[Farley, Peter x23353]

Thanks again Sri.  After reading those posts, I do see the issue.  That would 
be the "Don't break existing jobs" mantra.

I would instead have said "Go ahead and break them in QA so we can fix the 
broken ones", but I don't pay the bills and "breaking them in QA" AssUMes that 
QA batch initiator classes are distinct from Production batch initiator 
classes, which isn't true at any large shop where I have worked.

But I agree with Gil's final post in that thread - it should have been 
implemented as a new JCL option (similar to EXPORT SYMLIST) rather than an 
initiator class parameter.  Positive opt-in for jobs that want to use it, leave 
the others alone.  Perhaps a global parameter for the JCL interpreter to allow 
or disallow the new JCL option during the initial transition so shops could 
choose to allow or disallow use of the new JCL option to prevent accidental 
breakage by too-eager programmers until automated SDLC rules for JCL are 
updated and enforced.

Water under the proverbial bridge now.  At least we have EZACFSM1 as an 
alternative, so that's good.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Sri 
h Kolusu
Sent: Wednesday, June 15, 2022 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SFTP JOB Data parameter

>>> But that raises the question why NOT always allow system symbols in 
>>> every batch initiator?  Allowing them just seems like a no-brainer 
>>> to me

Peter,

There have been several discussions on IBM-MAIN about SYSSYM=ALLOW and here is 
a post which explains one of the reason.

https://www.mail-archive.com/ibm-main@listserv.ua.edu/msg62638.html 

Thanks,
Kolusu
--

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: [EXTERNAL] Re: SMS confusion on when system determined blocksize is used

[Pommier, Rex]

Hi Steve, 

None of my data classes have "force SDB" set.  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Smith
Sent: Wednesday, June 15, 2022 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: SMS confusion on when system determined blocksize 
is used

Check to see if your SMS ACS routine assigned a Data Class that has the "force 
SDB" option set.

sas

On Wed, Jun 15, 2022 at 12:42 PM Pommier, Rex 
wrote:

> Hi Mike,
>
> Good idea, unfortunately ours is set to NOBLOCK0.
>
> Rex
>
>

--
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: Rexx generic compare

[Rob Schramm]

I agree with you about TSSSIM.. but at least when you detect bad
responses.. you can open an issue to get it corrected.

Rob

On Wed, Jun 15, 2022 at 11:51 AM Bob Bridges  wrote:

> I like a lot of the features of TSS, but I agree about masking; RACF has
> far the better scheme.  I'm guessing that when they included the period
> among the characters that could be masked by an asterisk, it seemed to them
> like a brilliant idea.  But in my opinion, and as you say, it's a lot worse.
>
> I use TSSSIM a lot, but I'm not a big fan of batch operations for such a
> simple and fast-running function so I wrote a REXX (named TSIM) that'll let
> me invoke it as a command-line function.  You can spell out all the parms
> if you want -
>
>   ==> tso tsim acid(myid) fac(tso) dataset(my.dataset.name) acc(read)
>
> - but the REXX attempts a lot of assumptions for the missing ones so
>
>   ==> tso tsim myid my.dataset.name
>
> ...yields the same result.  Very handy.
>
> Incidentally, my go-to Horse's Mouth for TSS at CA tells me that even
> TSSSIM cannot be counted on to get ~every~ possible query right; there are
> complications within the TSS algorithm that TSSSIM can miss.  I gather,
> though, that they're rare enough that I don't worry about them.  It's just
> something I keep in mind; if ever TSS doesn't do what TSIM says it should,
> I'll remember then to look closer.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* The difference between British and Americans is that Americans think a
> hundred years is a long time, and the British think a hundred miles is a
> long drive.  -Unknown */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Rob Schramm
> Sent: Tuesday, June 14, 2022 23:12
>
> "*" for TSS is definitely 0.1 - 8
>
> "*" does not function like the RACF *.  It crosses indexes.  (unless there
> is a mod that changes the behavior)  This is very concerning when you have
> short indexes and naming convention collisions.
>
> The reason for the .1 is that if you add "*" to the end of a string lets
> say there are 2 permits TEMP.TST and TEMP.TST*   The * provides a better
> match even if the incoming data set for authorization is TEMP.TST.
>
> "+" is definitely one character
>
> "-" I never used this one.. so I can't comment
>
> Normally conflicting matches will choose the access level in the following
> order (this only occurs when certain control options are chosen)
> 1) none
> 2) all
> 3) lowest level  i.e. if there is READ and another has UPDATE.. READ will
> be chosen.
>
> You are correct about the "additional items" on the PERMIT like PROGRAM,
> LIBRARY, ACTION, CPU etc etc... which can create a best match.  Of course
> there are facility (tss facility not RACF facility) considerations, control
> options and other userID (aka ACID) issues that can affect the checking.
>
> Duplicating this is REXX.. well.. I would use TSSSIM or the data base
> unload which is supposed to include simulated checks.   There is also a
> LDAP with some library(s) to perform data set checking.  All I am saying is
> there is a lot to simulating it.  And just because you have the matching
> left to right working, doesn't mean that you have all the stuff correct.
>
> --- On Mon, Jun 13, 2022 at 5:02 PM Bob Bridges 
> wrote:
> > The TSS manual (v15) says it starts by looking for, simply, the
> > longest resource name:
> >
> > /* Quote begins */
> > To determine the longest resource name, each character in the resource
> > name counts as one character whether it is a normal character or a
> > masking character. If the floating mask “-“ is used in a PERMIT, only
> > count the characters prior to the mask. The following table contains
> > examples of how to count characters:
> >
> >   For ResourceNumber of Characters Counted
> >   SMITH.TEST.JCL  14, all characters are counted
> >   JONES.*.JCL 11, all characters are counted
> >   BROWN.-.JCL 6, only 'BROWN.' is counted
> > /* Quote ends */
> >
> > In TSS, masking characters are '+', '*' and '-'.  The plus sign is one
> > character.  I've heard conflicting things about the other two; at one
> > time I understood that the '*' could stand for any zero to eight
> > characters INCLUDING A PERIOD, so that GEN*FIT would match GENFIT,
> > GEN.FIT, GEN.XYZ.FIT or GENXX.XYZ.XFIT.  But it also says here it's
> > supposed to be about a single index.  One of these days I've got to
> > test this and see what the real story is.  The hyphen, it says here,
> > is a "floating" mask; they appear to mean it can represent any number of
> characters.
> >
> > If you have multiple permissions which by the above criteria are the
> > same length, then it looks at other features of the permissions to
> > determine a match.  For instance, if one of them says ACCESS(NONE),
> > that one controls regardless of other matters.  Failing that, it looks
> > at (for example) FACILITY, TIME, TERMINAL and so on.
>
> 

Re: [EXTERNAL] Re: SMS confusion on when system determined blocksize is used

[Steve Smith]

Check to see if your SMS ACS routine assigned a Data Class that has the
"force SDB" option set.

sas

On Wed, Jun 15, 2022 at 12:42 PM Pommier, Rex 
wrote:

> Hi Mike,
>
> Good idea, unfortunately ours is set to NOBLOCK0.
>
> Rex
>
>

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

Re: SFTP JOB Data parameter

[Carmen Vitullo]

reading the post sited, at least at my site no user would be allowed by 
security to create a dataset with the SYSTEM NAME as a HLQ or the entire 
dataset name, a discrete or generic TSS or RACF rule would need to be 
defined in a protect all environment - in my site


at my site all job classes are set to syssym allow and we have not seen 
any issues


so use at your own risk I suppose


Carmen

On 6/15/2022 12:31 PM, Sri h Kolusu wrote:

But that raises the question why NOT always allow system symbols in every batch 
initiator?  Allowing them just seems like a no-brainer to me

Peter,

There have been several discussions on IBM-MAIN about SYSSYM=ALLOW and here is 
a post which explains one of the reason.

https://www.mail-archive.com/ibm-main@listserv.ua.edu/msg62638.html


Thanks,
Kolusu

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



--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


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

Re: SFTP JOB Data parameter

[Michael Oujesky]

My guess is that resolution of dynamic symbols can differ each time 
they are interpreted,  In my JCL coding, I use refer-backs so that 
that any dataset is evaluated only once in the JCL.  Further 
references to that dataset do not use the dynamic symbol.


Michael

At 12:26 PM 6/15/2022, Farley, Peter x23353 wrote:
Thanks Sri, I did not know about SYSSYM=ALLOW.  But that raises the 
question why NOT always allow system symbols in every batch 
initiator?  Allowing them just seems like a no-brainer to me, but 
then I'm just an application programmer who expects to be able to 
use all of the available tools to get the job done.


Peter

-Original Message-
From: IBM Mainframe Discussion List  On 
Behalf Of Sri h Kolusu

Sent: Wednesday, June 15, 2022 1:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SFTP JOB Data parameter

>> Why is EZACFSM1 required to use  in an instream 
DD?  Couldn't the OP just use:


Peter,

Not all shops SYSSYM=ALLOW defined. So if your jobclass is NOT 
defined to allow symbols, the symbols will not be 
translated.  However with program EZACFSM1 will translate all the 
symbols defined to the system.



Thanks,
Kolusu
--

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


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


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

Re: SFTP JOB Data parameter

[Sri h Kolusu]

>>> But that raises the question why NOT always allow system symbols in every 
>>> batch initiator?  Allowing them just seems like a no-brainer to me

Peter,

There have been several discussions on IBM-MAIN about SYSSYM=ALLOW and here is 
a post which explains one of the reason.

https://www.mail-archive.com/ibm-main@listserv.ua.edu/msg62638.html


Thanks,
Kolusu

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

Re: RIsks of sharing FICON adapters between LPARs on the same host

[Tony Harminc]

On Wed, 15 Jun 2022 at 09:55, Seymour J Metz  wrote:
>
> Any time you have shared hardware there is a theoretical risk of  
> vulnerabilities, but I would be far more concerned with the brocade (what's 
> the generic term these days?)

Switch Fabric?

> than with the FICON adapter itself. There should be a STIG from DISA that 
> addresses the issue. I'd also check the hardware configurations on which z/OS 
> was last evaluated.

Tony H.

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

Re: SFTP JOB Data parameter

[Farley, Peter x23353]

Thanks Sri, I did not know about SYSSYM=ALLOW.  But that raises the question 
why NOT always allow system symbols in every batch initiator?  Allowing them 
just seems like a no-brainer to me, but then I'm just an application programmer 
who expects to be able to use all of the available tools to get the job done.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Sri 
h Kolusu
Sent: Wednesday, June 15, 2022 1:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SFTP JOB Data parameter

>> Why is EZACFSM1 required to use  in an instream DD?  Couldn't the OP 
>> just use:

Peter,

Not all shops SYSSYM=ALLOW defined. So if your jobclass is NOT defined to allow 
symbols, the symbols will not be translated.  However with program EZACFSM1 
will translate all the symbols defined to the system.


Thanks,
Kolusu
--

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: SFTP JOB Data parameter

[Sri h Kolusu]

>> Why is EZACFSM1 required to use  in an instream DD?  Couldn't the OP 
>> just use:

Peter,

Not all shops SYSSYM=ALLOW defined. So if your jobclass is NOT defined to allow 
symbols, the symbols will not be translated.  However with program EZACFSM1 
will translate all the symbols defined to the system.


Thanks,
Kolusu

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

Re: SFTP JOB Data parameter

[Bonnie Barthel]

Yes, it does not do the FTP, it only creates control cards to allow the use of 
system symbols.
https://www.ibm.com/docs/en/zos/2.4.0?topic=considerations-mvs-system-symbols

Bonnie Barthel
Senior IT Specialist
719.649.7888 Mobile
bonnie.bart...@kyndryl.com


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Sri 
h Kolusu
Sent: Wednesday, June 15, 2022 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: SFTP JOB Data parameter

>> Can we use PGM=EZACFSM1 with sftp also . I am not sure

Saurabh,

Bonnie meant provide the control cards to symbol translator program EZACFSM1 
and use those translated cards to perform the SFTP.  You use the dynamic system 
symbols for current date.  Here is the link to the symbols 
https://www.ibm.com/docs/en/zos/2.4.0?topic=symbols-dynamic-system 

Something like this

//STEP0EXEC PGM=EZACFSM1
//SYSOUT   DD DSN=&,DISP=(,PASS),SPACE=(TRK,(1,0))
//SYSINDD DATA,DLM=@@
OSHELL { ECHO 'LCD /U/OP117/';  +
 ECHO 'CD /FRB/EBCCLEARING/STAGING/TMP';+
 ECHO 'ASCII';  +
 ECHO 'GET EBC-GOV-MMDD.TXT'; } |   +
 SFTP -P  eftmfge...@10.222.xx.xx
 OGET '/U/OP117/EBC-GOV-' -
  'NBFDP.DATA.XX.XX.SFTP'
@@
//STEP1EXEC PGM=IKJEFT01,REGION=0M
//SYSEXEC  DD DISP=SHR,DSN=SYS1.SBPXEXEC
//OUTPUT   DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD DISP=(OLD,PASS),DSN=&


Thanks,
Kolusu


--
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: SFTP JOB Data parameter

[Farley, Peter x23353]

Why is EZACFSM1 required to use  in an instream DD?  Couldn't the OP 
just use:

//TSOUSERX JOB . . . 
// EXPORT SYMLIST=*
// SET MYDATE=
//SYSTSIN DD *,SYMBOLS=JCLONLY
CONTROL CARD UISNG 
/*

to substitute that value? (tested using IEBGENER with a SYSUT1 instream and 
SYSUT2 DD SYSOUT=*)

Using symbols in a regular file (Unix or MVS) of course requires EZACFSM1, but 
for an instream control card file it is not required.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Oujesky
Sent: Wednesday, June 15, 2022 11:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SFTP JOB Data parameter

As a starting point:
//SFTPSEBC JOB (7330),MSGCLASS=X,CLASS=P,NOTIFY=
//TAILOR  EXEC PGM=PGM=EZACFSM1
//SYSOUT   DD   DISP=(NEW,PASS,DELETE),DSN=,
// UNIT=VIO,SPACE=(TRK,(1)),
// RECFM=FB,LRECL=80,BLKSZE=800
//SYSINDD *
OSHELL { echo 'lcd /u/op117/';
  echo 'cd /FRB/EBCClearing/Staging/tmp';+
  echo 'ASCII'; +
  echo 'get EBC-GOV-'; } | +
sftp -P  eftmfge...@10.222.xx.xx
OGET '/u/op117/EBC-GOV-'  -
  'NBFDP.DATA.XX.XX.SFTP'
//STEP1   EXEC PGM=IKJEFT01,REGION=0M
//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC
//SYSTSIN   DD DSN=,DISP=(OLD,DELETE)
//OUTPUT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
/*

At 05:44 AM 6/15/2022, saurabh khandelwal wrote:
>--
>
>Dear All,
>
>I am am running below Job in TSO env and getting to get file file from 
>windows to Mainframe env.
>
>Initially file was static and all worked well. But now, requirement is 
>to get the file, which has current time stamp on daily basis.
>
>Ex : EBC-GOV-mmdd.txt'   in this mmdd should be replace with 
>year/month/date.
>
>But I am unable to find way to achieve this goal. Can you please help 
>on this issue.
>//SFTPSEBC JOB (7330),MSGCLASS=X,CLASS=P,NOTIFY=
>//STEP1   EXEC PGM=IKJEFT01,REGION=0M
>//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC
>//SYSTSIN   DD DSN=NP.LIB.CLIST(SFTPSEBC),DISP=SHR
>//OUTPUT DD SYSOUT=*
>//SYSTSPRT DD SYSOUT=*
>/*
>EDIT  NP.LIB.CLIST(SFTPSEBB) - 01.01Columns 1 00072
>Command ===>  Scroll ===> CSR
>07 OSHELL { echo 'lcd /u/op117/';
>08  echo 'cd /FRB/EBCClearing/Staging/tmp';+
>09  echo 'ASCII'; +
>10  echo 'get EBC-GOV-mmdd.txt'; } | +
>11sftp -P  eftmfge...@10.222.xx.xx
>12 OGET '/u/op117/EBC-GOV-mmdd.txt'  -
>13  'NBFDP.DATA.XX.XX.SFTP'
>
>**  Bottom of Data
>
--

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: SFTP JOB Data parameter

[Sri h Kolusu]

>> Can we use PGM=EZACFSM1 with sftp also . I am not sure

Saurabh,

Bonnie meant provide the control cards to symbol translator program EZACFSM1 
and use those translated cards to perform the SFTP.  You use the dynamic system 
symbols for current date.  Here is the link to the symbols 
https://www.ibm.com/docs/en/zos/2.4.0?topic=symbols-dynamic-system

Something like this

//STEP0EXEC PGM=EZACFSM1
//SYSOUT   DD DSN=&,DISP=(,PASS),SPACE=(TRK,(1,0))
//SYSINDD DATA,DLM=@@
OSHELL { ECHO 'LCD /U/OP117/';  +
 ECHO 'CD /FRB/EBCCLEARING/STAGING/TMP';+
 ECHO 'ASCII';  +
 ECHO 'GET EBC-GOV-MMDD.TXT'; } |   +
 SFTP -P  eftmfge...@10.222.xx.xx
 OGET '/U/OP117/EBC-GOV-' -
  'NBFDP.DATA.XX.XX.SFTP'
@@
//STEP1EXEC PGM=IKJEFT01,REGION=0M
//SYSEXEC  DD DISP=SHR,DSN=SYS1.SBPXEXEC
//OUTPUT   DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD DISP=(OLD,PASS),DSN=&


Thanks,
Kolusu


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

Re: [EXTERNAL] Re: SMS confusion on when system determined blocksize is used

[Pommier, Rex]

Hi Mike,

Good idea, unfortunately ours is set to NOBLOCK0.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Wednesday, June 15, 2022 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: SMS confusion on when system determined blocksize is 
used

https://urldefense.com/v3/__https://www.ibm.com/docs/en/cobol-zos/6.2?topic=entries-block-contains-clause__;!!KjMRP1Ixj6eLE0Fj!oJY-2fhgmnSNMdOJkIfL_jo2PmgBjGAwMAZ2SwMPSSymNSwsNvBUlpJ3DEw4OT319g1w6TmoFYKmOtRok3CSuqVxmg$
 

Is BLOCK0 specified as a compiler option?

For a way to apply BLOCK CONTAINS 0 to QSAM files that do not already have a 
BLOCK CONTAINS clause, see the description of the compiler option, BLOCK0 in 
the Enterprise COBOL Programming Guide

On Wed, Jun 15, 2022 at 8:34 AM Seymour J Metz  wrote:
>
> No, RECFM=F is unblocked, whether you use BSAM, QSAM or something else, 
> regardless of whether it is on DASD or tape and regardless of whether it is 
> SMS managed.. It means that the access method makes no attempt to block or 
> unblock logical records. Think of it as RECFM=FB with LRECL and BLKSIZE the 
> same.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!KjMRP1I
> xj6eLE0Fj!oJY-2fhgmnSNMdOJkIfL_jo2PmgBjGAwMAZ2SwMPSSymNSwsNvBUlpJ3DEw4
> OT319g1w6TmoFYKmOtRok3B6Cb1how$
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
> behalf of Rob Schramm [rob.schr...@gmail.com]
> Sent: Tuesday, June 14, 2022 11:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMS confusion on when system determined blocksize is used
>
> Pretty sure the Using Data Sets should describe what is happening.
>
> I do not understand is the Non-sms data set that you say is unblocked.
> What does that even mean?  If it is on disk and QSAM .. it is blocked.
> SDB should work regardless of SMS or non-sms as long as blksize=0 and 
> the other caveats in the SDB section are met.
>
> Also.. you say that the Tape data set is unblocked.. I question that as
> well.   But I don't see that you included the data set information for the
> non-sms and the tape data sets.
>
> Rob.
>
>
> On Tue, Jun 14, 2022 at 6:07 PM Pommier, Rex 
> wrote:
>
> > Hi list,
> >
> > I had a strange one thrown to me from a developer and I'm hoping 
> > somebody can point me to something to explain why this is happening.  
> > Environment is z/OS 2.4 and Cobol 6.3,pretty vanilla.  I've read 
> > through SDB explanations in several manuals but haven't found the 
> > explanation as to why this is happening.
> >
> > We have a Cobol program with record length 200, and the developer 
> > inadvertently omitted the BLOCK CONTAINS 0 RECORDS  clause which 
> > according to the Cobol manual says the file is supposed to be 
> > unblocked.  Developer runs the program in batch using a DD card like 
> > this for the unblocked dataset.
> >
> > //VSF  DD DSN=TEST.DATASET.NAME,
> > //DISP=(NEW,CATLG,DELETE),
> > //*   UNIT=VTS,
> > //UNIT=SYSDA,
> > //SPACE=(CYL,(5,20),RLSE),
> > //DCB=MDCB.TEST.DATASET.NAME
> >
> > The only DCB information provided is in the MDCB statement which 
> > looks like this:
> >
> >  % XT Device  Dsorg Recfm Lrecl Blksz
> > --
> > MDCB.TEST.DATASET.NAME
> >   0   ? 0 3390  FB  200 0
> >
> > Sorry for the lack of formatting, BLKSIZE=0, LRECL=200, RECFM=FB.
> >
> > If he runs his job with the DD card as above, going to an SMS 
> > managed dataset, he gets half track blocking.  If he runs it 
> > changing it to UNIT=VTS, he gets an unblocked dataset, and if he 
> > runs it against DASD with an unmanaged dataset name, he also gets it 
> > unblocked.  Definitely makes it look like something in the SMS 
> > configuration, however, our SMS dataclas that this dataset falls 
> > under does not specify to use SDB that I could find.  So my 
> > questions are how to explain what's happening here?  Why does the 
> > MDCB specification of SDB seem to override the Cobol program in the 
> > case of the SMS managed dataset but the Cobol program overrides the MDCB 
> > for the non-SMS datasets?
> >
> > 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, 

Re: [EXTERNAL] Re: SMS confusion on when system determined blocksize is used

[Pommier, Rex]

My bad on this.  When I said "unblocked" I wasn't precise enough as Shmuel 
pointed out.  The datasets are showing up as FB with LRECL=BLKSIZE=200.  They 
are not showing as RECFM=F.

I'm checking the compile options.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Wednesday, June 15, 2022 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: SMS confusion on when system determined blocksize is 
used

https://urldefense.com/v3/__https://www.ibm.com/docs/en/cobol-zos/6.2?topic=entries-block-contains-clause__;!!KjMRP1Ixj6eLE0Fj!oJY-2fhgmnSNMdOJkIfL_jo2PmgBjGAwMAZ2SwMPSSymNSwsNvBUlpJ3DEw4OT319g1w6TmoFYKmOtRok3CSuqVxmg$
 

Is BLOCK0 specified as a compiler option?

For a way to apply BLOCK CONTAINS 0 to QSAM files that do not already have a 
BLOCK CONTAINS clause, see the description of the compiler option, BLOCK0 in 
the Enterprise COBOL Programming Guide

On Wed, Jun 15, 2022 at 8:34 AM Seymour J Metz  wrote:
>
> No, RECFM=F is unblocked, whether you use BSAM, QSAM or something else, 
> regardless of whether it is on DASD or tape and regardless of whether it is 
> SMS managed.. It means that the access method makes no attempt to block or 
> unblock logical records. Think of it as RECFM=FB with LRECL and BLKSIZE the 
> same.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!KjMRP1I
> xj6eLE0Fj!oJY-2fhgmnSNMdOJkIfL_jo2PmgBjGAwMAZ2SwMPSSymNSwsNvBUlpJ3DEw4
> OT319g1w6TmoFYKmOtRok3B6Cb1how$
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
> behalf of Rob Schramm [rob.schr...@gmail.com]
> Sent: Tuesday, June 14, 2022 11:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMS confusion on when system determined blocksize is used
>
> Pretty sure the Using Data Sets should describe what is happening.
>
> I do not understand is the Non-sms data set that you say is unblocked.
> What does that even mean?  If it is on disk and QSAM .. it is blocked.
> SDB should work regardless of SMS or non-sms as long as blksize=0 and 
> the other caveats in the SDB section are met.
>
> Also.. you say that the Tape data set is unblocked.. I question that as
> well.   But I don't see that you included the data set information for the
> non-sms and the tape data sets.
>
> Rob.
>
>
> On Tue, Jun 14, 2022 at 6:07 PM Pommier, Rex 
> wrote:
>
> > Hi list,
> >
> > I had a strange one thrown to me from a developer and I'm hoping 
> > somebody can point me to something to explain why this is happening.  
> > Environment is z/OS 2.4 and Cobol 6.3,pretty vanilla.  I've read 
> > through SDB explanations in several manuals but haven't found the 
> > explanation as to why this is happening.
> >
> > We have a Cobol program with record length 200, and the developer 
> > inadvertently omitted the BLOCK CONTAINS 0 RECORDS  clause which 
> > according to the Cobol manual says the file is supposed to be 
> > unblocked.  Developer runs the program in batch using a DD card like 
> > this for the unblocked dataset.
> >
> > //VSF  DD DSN=TEST.DATASET.NAME,
> > //DISP=(NEW,CATLG,DELETE),
> > //*   UNIT=VTS,
> > //UNIT=SYSDA,
> > //SPACE=(CYL,(5,20),RLSE),
> > //DCB=MDCB.TEST.DATASET.NAME
> >
> > The only DCB information provided is in the MDCB statement which 
> > looks like this:
> >
> >  % XT Device  Dsorg Recfm Lrecl Blksz
> > --
> > MDCB.TEST.DATASET.NAME
> >   0   ? 0 3390  FB  200 0
> >
> > Sorry for the lack of formatting, BLKSIZE=0, LRECL=200, RECFM=FB.
> >
> > If he runs his job with the DD card as above, going to an SMS 
> > managed dataset, he gets half track blocking.  If he runs it 
> > changing it to UNIT=VTS, he gets an unblocked dataset, and if he 
> > runs it against DASD with an unmanaged dataset name, he also gets it 
> > unblocked.  Definitely makes it look like something in the SMS 
> > configuration, however, our SMS dataclas that this dataset falls 
> > under does not specify to use SDB that I could find.  So my 
> > questions are how to explain what's happening here?  Why does the 
> > MDCB specification of SDB seem to override the Cobol program in the 
> > case of the SMS managed dataset but the Cobol program overrides the MDCB 
> > for the non-SMS datasets?
> >
> > 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 

Re: Rexx generic compare

[Bob Bridges]

I like a lot of the features of TSS, but I agree about masking; RACF has far 
the better scheme.  I'm guessing that when they included the period among the 
characters that could be masked by an asterisk, it seemed to them like a 
brilliant idea.  But in my opinion, and as you say, it's a lot worse.

I use TSSSIM a lot, but I'm not a big fan of batch operations for such a simple 
and fast-running function so I wrote a REXX (named TSIM) that'll let me invoke 
it as a command-line function.  You can spell out all the parms if you want -

  ==> tso tsim acid(myid) fac(tso) dataset(my.dataset.name) acc(read)

- but the REXX attempts a lot of assumptions for the missing ones so

  ==> tso tsim myid my.dataset.name

...yields the same result.  Very handy.

Incidentally, my go-to Horse's Mouth for TSS at CA tells me that even TSSSIM 
cannot be counted on to get ~every~ possible query right; there are 
complications within the TSS algorithm that TSSSIM can miss.  I gather, though, 
that they're rare enough that I don't worry about them.  It's just something I 
keep in mind; if ever TSS doesn't do what TSIM says it should, I'll remember 
then to look closer.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* The difference between British and Americans is that Americans think a 
hundred years is a long time, and the British think a hundred miles is a long 
drive.  -Unknown */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Schramm
Sent: Tuesday, June 14, 2022 23:12

"*" for TSS is definitely 0.1 - 8

"*" does not function like the RACF *.  It crosses indexes.  (unless there is a 
mod that changes the behavior)  This is very concerning when you have short 
indexes and naming convention collisions.

The reason for the .1 is that if you add "*" to the end of a string lets
say there are 2 permits TEMP.TST and TEMP.TST*   The * provides a better
match even if the incoming data set for authorization is TEMP.TST.

"+" is definitely one character

"-" I never used this one.. so I can't comment

Normally conflicting matches will choose the access level in the following 
order (this only occurs when certain control options are chosen)
1) none
2) all
3) lowest level  i.e. if there is READ and another has UPDATE.. READ will be 
chosen.

You are correct about the "additional items" on the PERMIT like PROGRAM, 
LIBRARY, ACTION, CPU etc etc... which can create a best match.  Of course there 
are facility (tss facility not RACF facility) considerations, control options 
and other userID (aka ACID) issues that can affect the checking.

Duplicating this is REXX.. well.. I would use TSSSIM or the data base unload 
which is supposed to include simulated checks.   There is also a LDAP with some 
library(s) to perform data set checking.  All I am saying is there is a lot to 
simulating it.  And just because you have the matching left to right working, 
doesn't mean that you have all the stuff correct.

--- On Mon, Jun 13, 2022 at 5:02 PM Bob Bridges  wrote:
> The TSS manual (v15) says it starts by looking for, simply, the 
> longest resource name:
>
> /* Quote begins */
> To determine the longest resource name, each character in the resource 
> name counts as one character whether it is a normal character or a 
> masking character. If the floating mask “-“ is used in a PERMIT, only 
> count the characters prior to the mask. The following table contains 
> examples of how to count characters:
>
>   For ResourceNumber of Characters Counted
>   SMITH.TEST.JCL  14, all characters are counted
>   JONES.*.JCL 11, all characters are counted
>   BROWN.-.JCL 6, only 'BROWN.' is counted
> /* Quote ends */
>
> In TSS, masking characters are '+', '*' and '-'.  The plus sign is one 
> character.  I've heard conflicting things about the other two; at one 
> time I understood that the '*' could stand for any zero to eight 
> characters INCLUDING A PERIOD, so that GEN*FIT would match GENFIT, 
> GEN.FIT, GEN.XYZ.FIT or GENXX.XYZ.XFIT.  But it also says here it's 
> supposed to be about a single index.  One of these days I've got to 
> test this and see what the real story is.  The hyphen, it says here, 
> is a "floating" mask; they appear to mean it can represent any number of 
> characters.
>
> If you have multiple permissions which by the above criteria are the 
> same length, then it looks at other features of the permissions to 
> determine a match.  For instance, if one of them says ACCESS(NONE), 
> that one controls regardless of other matters.  Failing that, it looks 
> at (for example) FACILITY, TIME, TERMINAL and so on.

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

Re: SFTP JOB Data parameter

[Michael Oujesky]

As a starting point:
//SFTPSEBC JOB (7330),MSGCLASS=X,CLASS=P,NOTIFY=
//TAILOR  EXEC PGM=PGM=EZACFSM1
//SYSOUT   DD   DISP=(NEW,PASS,DELETE),DSN=,
// UNIT=VIO,SPACE=(TRK,(1)),
// RECFM=FB,LRECL=80,BLKSZE=800
//SYSINDD *
OSHELL { echo 'lcd /u/op117/';
 echo 'cd /FRB/EBCClearing/Staging/tmp';+
 echo 'ASCII'; +
 echo 'get EBC-GOV-'; } | +
   sftp -P  eftmfge...@10.222.xx.xx
OGET '/u/op117/EBC-GOV-'  -
 'NBFDP.DATA.XX.XX.SFTP'
//STEP1   EXEC PGM=IKJEFT01,REGION=0M
//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC
//SYSTSIN   DD DSN=,DISP=(OLD,DELETE)
//OUTPUT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
/*

At 05:44 AM 6/15/2022, saurabh khandelwal wrote:

--

Dear All,

I am am running below Job in TSO env and getting to get file file 
from windows to Mainframe env.


Initially file was static and all worked well. But now, requirement 
is to get the file, which has current time stamp on daily basis.


Ex : EBC-GOV-mmdd.txt'   in this mmdd should be replace with 
year/month/date.


But I am unable to find way to achieve this goal. Can you please 
help on this issue.

//SFTPSEBC JOB (7330),MSGCLASS=X,CLASS=P,NOTIFY=
//STEP1   EXEC PGM=IKJEFT01,REGION=0M
//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC
//SYSTSIN   DD DSN=NP.LIB.CLIST(SFTPSEBC),DISP=SHR
//OUTPUT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
/*
EDIT  NP.LIB.CLIST(SFTPSEBB) - 01.01Columns 1 00072
Command ===>  Scroll ===> CSR
07 OSHELL { echo 'lcd /u/op117/';
08  echo 'cd /FRB/EBCClearing/Staging/tmp';+
09  echo 'ASCII'; +
10  echo 'get EBC-GOV-mmdd.txt'; } | +
11sftp -P  eftmfge...@10.222.xx.xx
12 OGET '/u/op117/EBC-GOV-mmdd.txt'  -
13  'NBFDP.DATA.XX.XX.SFTP'

**  Bottom of Data 



--
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: SMS confusion on when system determined blocksize is used

[Mike Schwab]

https://www.ibm.com/docs/en/cobol-zos/6.2?topic=entries-block-contains-clause

Is BLOCK0 specified as a compiler option?

For a way to apply BLOCK CONTAINS 0 to QSAM files that do not already
have a BLOCK CONTAINS clause, see the description of the compiler
option, BLOCK0 in the Enterprise COBOL Programming Guide

On Wed, Jun 15, 2022 at 8:34 AM Seymour J Metz  wrote:
>
> No, RECFM=F is unblocked, whether you use BSAM, QSAM or something else, 
> regardless of whether it is on DASD or tape and regardless of whether it is 
> SMS managed.. It means that the access method makes no attempt to block or 
> unblock logical records. Think of it as RECFM=FB with LRECL and BLKSIZE the 
> same.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Rob Schramm [rob.schr...@gmail.com]
> Sent: Tuesday, June 14, 2022 11:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMS confusion on when system determined blocksize is used
>
> Pretty sure the Using Data Sets should describe what is happening.
>
> I do not understand is the Non-sms data set that you say is unblocked.
> What does that even mean?  If it is on disk and QSAM .. it is blocked.
> SDB should work regardless of SMS or non-sms as long as blksize=0 and the
> other caveats in the SDB section are met.
>
> Also.. you say that the Tape data set is unblocked.. I question that as
> well.   But I don't see that you included the data set information for the
> non-sms and the tape data sets.
>
> Rob.
>
>
> On Tue, Jun 14, 2022 at 6:07 PM Pommier, Rex 
> wrote:
>
> > Hi list,
> >
> > I had a strange one thrown to me from a developer and I'm hoping somebody
> > can point me to something to explain why this is happening.  Environment is
> > z/OS 2.4 and Cobol 6.3,pretty vanilla.  I've read through SDB explanations
> > in several manuals but haven't found the explanation as to why this is
> > happening.
> >
> > We have a Cobol program with record length 200, and the developer
> > inadvertently omitted the BLOCK CONTAINS 0 RECORDS  clause which according
> > to the Cobol manual says the file is supposed to be unblocked.  Developer
> > runs the program in batch using a DD card like this for the unblocked
> > dataset.
> >
> > //VSF  DD DSN=TEST.DATASET.NAME,
> > //DISP=(NEW,CATLG,DELETE),
> > //*   UNIT=VTS,
> > //UNIT=SYSDA,
> > //SPACE=(CYL,(5,20),RLSE),
> > //DCB=MDCB.TEST.DATASET.NAME
> >
> > The only DCB information provided is in the MDCB statement which looks
> > like this:
> >
> >  % XT Device  Dsorg Recfm Lrecl Blksz
> > --
> > MDCB.TEST.DATASET.NAME
> >   0   ? 0 3390  FB  200 0
> >
> > Sorry for the lack of formatting, BLKSIZE=0, LRECL=200, RECFM=FB.
> >
> > If he runs his job with the DD card as above, going to an SMS managed
> > dataset, he gets half track blocking.  If he runs it changing it to
> > UNIT=VTS, he gets an unblocked dataset, and if he runs it against DASD with
> > an unmanaged dataset name, he also gets it unblocked.  Definitely makes it
> > look like something in the SMS configuration, however, our SMS dataclas
> > that this dataset falls under does not specify to use SDB that I could
> > find.  So my questions are how to explain what's happening here?  Why does
> > the MDCB specification of SDB seem to override the Cobol program in the
> > case of the SMS managed dataset but the Cobol program overrides the MDCB
> > for the non-SMS datasets?
> >
> > TIA,
> >
> > Rex
> >
> > --
> > The information contained in this message is confidential, protected from
> > disclosure and may be legally privileged. If the reader of this message is
> > not the intended recipient or an employee or agent responsible for
> > delivering this message to the intended recipient, you are hereby notified
> > that any disclosure, distribution, copying, or any action taken or action
> > omitted in reliance on it, is strictly prohibited and may be unlawful. If
> > you have received this communication in error, please notify us immediately
> > by replying to this message and destroy the material in its entirety,
> > whether in electronic or hard copy format. Thank you.
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> 

Re: SFTP JOB Data parameter

[saurabh khandelwal]

Dear Bonnie,

Can we use PGM=EZACFSM1 with sftp also . I am not sure

On Wed, Jun 15, 2022, 17:37 Bonnie Barthel 
wrote:

> Look up PGM=EZACFSM1... it may be what you are looking for.
>
> Bonnie Barthel
> Senior IT Specialist
> 719.649.7888 Mobile
> bonnie.bart...@kyndryl.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Paul Gilmartin
> Sent: Wednesday, June 15, 2022 8:08 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: SFTP JOB Data parameter
>
> On Wed, 15 Jun 2022 13:11:05 +, Seymour J Metz  wrote:
>
> >Write a REXX script to do the file transfer. You can use the date('S')
> function to generate the date in the format mmdd, then parse out the
> component to build your dsn.
> >
> I would have done something similar.  But the OP was on a promising track,
> however circuitous, even reporting a partial success.  Let's not deflect
> him.
>
> --
> 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: SFTP JOB Data parameter

[saurabh khandelwal]

Hello Paul,

If I use rexx then how will I be able to use shell command in same job

On Wed, Jun 15, 2022, 17:08 Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 15 Jun 2022 13:11:05 +, Seymour J Metz  wrote:
>
> >Write a REXX script to do the file transfer. You can use the date('S')
> function to generate the date in the format mmdd, then parse out the
> component to build your dsn.
> >
> I would have done something similar.  But the OP was on a promising track,
> however circuitous, even reporting a partial success.  Let's not deflect
> him.
>
> --
> 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: SFTP JOB Data parameter

[Bonnie Barthel]

Look up PGM=EZACFSM1... it may be what you are looking for.

Bonnie Barthel
Senior IT Specialist
719.649.7888 Mobile
bonnie.bart...@kyndryl.com


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Wednesday, June 15, 2022 8:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: SFTP JOB Data parameter

On Wed, 15 Jun 2022 13:11:05 +, Seymour J Metz  wrote:

>Write a REXX script to do the file transfer. You can use the date('S') 
>function to generate the date in the format mmdd, then parse out the 
>component to build your dsn.
>
I would have done something similar.  But the OP was on a promising track, 
however circuitous, even reporting a partial success.  Let's not deflect him.

--
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: SFTP JOB Data parameter

[Paul Gilmartin]

On Wed, 15 Jun 2022 13:11:05 +, Seymour J Metz  wrote:

>Write a REXX script to do the file transfer. You can use the date('S') 
>function to generate the date in the format mmdd, then parse out the 
>component to build your dsn.
>
I would have done something similar.  But the OP was on a promising track,
however circuitous, even reporting a partial success.  Let's not deflect him.

-- 
gil

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

Re: SMS confusion on when system determined blocksize is used

[Seymour J Metz]

What is "unblocked"? There is a difference between 
RECFM=F,LRECL=200,BLKSIZE=200 and RECFM=FB,LRECL=200,BLKSIZE=200?

You may want to submit an RCF against the COBOL documentation asking for 
clarification.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Pommier, Rex [rpomm...@sfgmembers.com]
Sent: Tuesday, June 14, 2022 6:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMS confusion on when system determined blocksize is used

Hi list,

I had a strange one thrown to me from a developer and I'm hoping somebody can 
point me to something to explain why this is happening.  Environment is z/OS 
2.4 and Cobol 6.3,pretty vanilla.  I've read through SDB explanations in 
several manuals but haven't found the explanation as to why this is happening.

We have a Cobol program with record length 200, and the developer inadvertently 
omitted the BLOCK CONTAINS 0 RECORDS  clause which according to the Cobol 
manual says the file is supposed to be unblocked.  Developer runs the program 
in batch using a DD card like this for the unblocked dataset.

//VSF  DD DSN=TEST.DATASET.NAME,
//DISP=(NEW,CATLG,DELETE),
//*   UNIT=VTS,
//UNIT=SYSDA,
//SPACE=(CYL,(5,20),RLSE),
//DCB=MDCB.TEST.DATASET.NAME

The only DCB information provided is in the MDCB statement which looks like 
this:

 % XT Device  Dsorg Recfm Lrecl Blksz
--
MDCB.TEST.DATASET.NAME
  0   ? 0 3390  FB  200 0

Sorry for the lack of formatting, BLKSIZE=0, LRECL=200, RECFM=FB.

If he runs his job with the DD card as above, going to an SMS managed dataset, 
he gets half track blocking.  If he runs it changing it to UNIT=VTS, he gets an 
unblocked dataset, and if he runs it against DASD with an unmanaged dataset 
name, he also gets it unblocked.  Definitely makes it look like something in 
the SMS configuration, however, our SMS dataclas that this dataset falls under 
does not specify to use SDB that I could find.  So my questions are how to 
explain what's happening here?  Why does the MDCB specification of SDB seem to 
override the Cobol program in the case of the SMS managed dataset but the Cobol 
program overrides the MDCB for the non-SMS datasets?

TIA,

Rex

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

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

Re: SFTP JOB Data parameter

[Paul Gilmartin]

On Wed, 15 Jun 2022 15:58:57 +0300, saurabh khandelwal wrote:
>
>Thank for reply but system doesn't take %D as date variable.  It taking as
>file name. So variable in file mmdd not getting replaced with actual
>date
>
%D is not a "date variable".  It is a substitution element in the argument
to the "date" command.

Did you try my suggestion:
date '+get EBC-GOV-%D.txt'
???

>On Wed, Jun 15, 2022, 15:54 Paul Gilmartin wrote:
>> >
>> >I am am running below Job in TSO env and getting to get file file from
>> >windows to Mainframe env.
>> >
>> >Initially file was static and all worked well. But now, requirement is to
>> >get the file, which has current time stamp on daily basis.
>> >
>> >Ex : EBC-GOV-mmdd.txt'   in this mmdd should be replace with
>> >year/month/date.
>> >
>> # Change:
>> echo 'get EBC-GOV-mmdd.txt'
>>
>> # to
>> date '+get EBC-GOV-%D.txt'

-- 
gil

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

Re: RIsks of sharing FICON adapters between LPARs on the same host

[Seymour J Metz]

Any time you have shared hardware there is a theoretical risk of  
vulnerabilities, but I would be far more concerned with the brocade (what's the 
generic term these days?) than with the FICON adapter itself. There should be a 
STIG from DISA that addresses the issue. I'd also check the hardware 
configurations on which z/OS was last evaluated.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Laurence Chiu [lch...@gmail.com]
Sent: Tuesday, June 14, 2022 10:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RIsks of sharing FICON adapters between LPARs on the same host

We had an interesting question raised recently in my work place by our
security team.

They said, if you have multiple LPARs on a Z box and you share FICON
adapters going to the same DS8K is there any data leak issue that could
occur? That is,  could LPAR1 inadvertently see traffic to the SAN that is
defined for LPAR2 but sharing the same FICON adapter. Maybe somebody mixed
up the IODF or something like that?

I thought not and said, isn't that how VMware and Hiper-V work. The
hypervisors share out FC cards etc. to the various VM's and it doesn't seem
to be an issue and z/OS (or is PR/SM) is likely to be a much hardier OS
security wise.

Anyway I would get the view of the experts on the forum.

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: [EXTERNAL] Re: SMS confusion on when system determined blocksize is used

[Pommier, Rex]

Hi Rob,

What I meant to say is that when the programmer came to me he said that when he 
ran the same job with the same program, only changing the JCL to move this 
output dataset from SMS managed disk to tape or to non-SMS managed disk, the 
blocking factor changed.  To wit:

Run 1 - result is blocked dataset at half track:
//VSF  DD DSN=TEST.DATASET.NAME,   <<< DSN HLQ pointing to SMS disk
//DISP=(NEW,CATLG,DELETE),
//*   UNIT=VTS,
//UNIT=SYSDA, send to disk
//SPACE=(CYL,(5,20),RLSE),
//DCB=MDCB.TEST.DATASET.NAME
 

Run 2 - result is dataset with 200 byte blocks:
//VSF  DD DSN=TEST.DATASET.NAME,   <<< DSN HLQ pointing to VTS tape
//DISP=(NEW,CATLG,DELETE),
//UNIT=VTS,  send to tape
//*  UNIT=SYSDA,
//*  SPACE=(CYL,(5,20),RLSE),
//DCB=MDCB.TEST.DATASET.NAME


Run 3 - result is dataset with 200 byte blocks:
//VSF  DD DSN=NONSMS.DATASET.NAME,   <<< DSN HLQ pointing to non-SMS disk
//DISP=(NEW,CATLG,DELETE),
//*   UNIT=VTS,
//UNIT=SYSDA, send to disk
//SPACE=(CYL,(5,20),RLSE),
//DCB=MDCB.TEST.DATASET.NAME

The only difference in the 3 runs was where he was sending the output of this 
DD card.  The result of sending //VSF to SMS disk was that it was half track 
blocked, sending the //VSF to either tape or to non-SMS disk resulted in the 
dataset being not blocked.  

Also, per an offline response, I checked my DEVSUPxx members and I don't have 
COPYSDB or TAPEBLKSIZELIM defined.  

Rex


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Schramm
Sent: Tuesday, June 14, 2022 10:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: SMS confusion on when system determined blocksize is 
used

Pretty sure the Using Data Sets should describe what is happening.

I do not understand is the Non-sms data set that you say is unblocked.
What does that even mean?  If it is on disk and QSAM .. it is blocked.
SDB should work regardless of SMS or non-sms as long as blksize=0 and the other 
caveats in the SDB section are met.

Also.. you say that the Tape data set is unblocked.. I question that as
well.   But I don't see that you included the data set information for the
non-sms and the tape data sets.

Rob.


On Tue, Jun 14, 2022 at 6:07 PM Pommier, Rex 
wrote:

> Hi list,
>
> I had a strange one thrown to me from a developer and I'm hoping 
> somebody can point me to something to explain why this is happening.  
> Environment is z/OS 2.4 and Cobol 6.3,pretty vanilla.  I've read 
> through SDB explanations in several manuals but haven't found the 
> explanation as to why this is happening.
>
> We have a Cobol program with record length 200, and the developer 
> inadvertently omitted the BLOCK CONTAINS 0 RECORDS  clause which 
> according to the Cobol manual says the file is supposed to be 
> unblocked.  Developer runs the program in batch using a DD card like 
> this for the unblocked dataset.
>
> //VSF  DD DSN=TEST.DATASET.NAME,
> //DISP=(NEW,CATLG,DELETE),
> //*   UNIT=VTS,
> //UNIT=SYSDA,
> //SPACE=(CYL,(5,20),RLSE),
> //DCB=MDCB.TEST.DATASET.NAME
>
> The only DCB information provided is in the MDCB statement which looks 
> like this:
>
>  % XT Device  Dsorg Recfm Lrecl Blksz
> --
> MDCB.TEST.DATASET.NAME
>   0   ? 0 3390  FB  200 0
>
> Sorry for the lack of formatting, BLKSIZE=0, LRECL=200, RECFM=FB.
>
> If he runs his job with the DD card as above, going to an SMS managed 
> dataset, he gets half track blocking.  If he runs it changing it to 
> UNIT=VTS, he gets an unblocked dataset, and if he runs it against DASD 
> with an unmanaged dataset name, he also gets it unblocked.  Definitely 
> makes it look like something in the SMS configuration, however, our 
> SMS dataclas that this dataset falls under does not specify to use SDB 
> that I could find.  So my questions are how to explain what's 
> happening here?  Why does the MDCB specification of SDB seem to 
> override the Cobol program in the case of the SMS managed dataset but 
> the Cobol program overrides the MDCB for the non-SMS datasets?
>
> 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 

Re: RIsks of sharing FICON adapters between LPARs on the same host

[Seymour J Metz]

a Subchannel-Set Identifier/Subchannel Number has a set of Channel-Path 
Identifiers (CHPIDs), each of which has an associated Physical-Channel-Path 
Identifier(PCHID) . The unit and control unit are part of the Device Identifier.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
kekronbekron [02dee3fcae33-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, June 14, 2022 10:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RIsks of sharing FICON adapters between LPARs on the same host

Somebody mixing up the IODF is a far bigger problem for the LPARs operationally 
first... let alone security.
If a CHPID is shared between the 2 LPARs, then yes, the pipe is shared.

But is it a security "gotcha"? Unlikely to hell and back.
I think this goes down to microcode and I would bet that IBM test these things 
out for 'leaks' thoroughly.

Anyway, if you do let your security know that the CHPID is shared, be prepared 
for many months and years of isolated CHPID talk, etc.

Do correct me if I'm wrong:

LPAR <-> unit <-> control unit <-> chpid <-> pchid <-> FC switch

I don't believe there's room for a "whoopsie, I sent to this LPAR instead".
Can't quite explain it clearly.
Someone like Timothy Sipples can do that magic!

- KB

--- Original Message ---
On Wednesday, June 15th, 2022 at 7:36 AM, Laurence Chiu  
wrote:


> We had an interesting question raised recently in my work place by our
> security team.
>
> They said, if you have multiple LPARs on a Z box and you share FICON
> adapters going to the same DS8K is there any data leak issue that could
> occur? That is, could LPAR1 inadvertently see traffic to the SAN that is
> defined for LPAR2 but sharing the same FICON adapter. Maybe somebody mixed
> up the IODF or something like that?
>
> I thought not and said, isn't that how VMware and Hiper-V work. The
> hypervisors share out FC cards etc. to the various VM's and it doesn't seem
> to be an issue and z/OS (or is PR/SM) is likely to be a much hardier OS
> security wise.
>
> Anyway I would get the view of the experts on the forum.
>
> 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

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

Re: Is there a service similar to TCTL so that a task can give control to another task?

[Peter Relson]

As I read the posts, the OP does not really want the functionality that the 
subject seems to state (or that I was thinking, anyway: stop running me and 
start running the other). They want the initial task to keep running for a 
while. If the other task is a new task, then Ed Jaffe's suggestion of ATTACHing 
with DISP=NO seems like a good approach (or have the task when it starts wait 
on a 'ready to proceed' ECB). If the other task is an existing task, then don't 
wake it up until you're ready for it to run.

Everything in dispatching in the system is a question of priority. The system 
isn't going to listen to you in general about what you think you want to run 
next. You make a work unit ready to run (such as by posting an ECB that an RB 
is waiting on). When the work unit gets dispatched is not within your control.

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: SMS confusion on when system determined blocksize is used

[Seymour J Metz]

No, RECFM=F is unblocked, whether you use BSAM, QSAM or something else, 
regardless of whether it is on DASD or tape and regardless of whether it is SMS 
managed.. It means that the access method makes no attempt to block or unblock 
logical records. Think of it as RECFM=FB with LRECL and BLKSIZE the same.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Rob 
Schramm [rob.schr...@gmail.com]
Sent: Tuesday, June 14, 2022 11:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMS confusion on when system determined blocksize is used

Pretty sure the Using Data Sets should describe what is happening.

I do not understand is the Non-sms data set that you say is unblocked.
What does that even mean?  If it is on disk and QSAM .. it is blocked.
SDB should work regardless of SMS or non-sms as long as blksize=0 and the
other caveats in the SDB section are met.

Also.. you say that the Tape data set is unblocked.. I question that as
well.   But I don't see that you included the data set information for the
non-sms and the tape data sets.

Rob.


On Tue, Jun 14, 2022 at 6:07 PM Pommier, Rex 
wrote:

> Hi list,
>
> I had a strange one thrown to me from a developer and I'm hoping somebody
> can point me to something to explain why this is happening.  Environment is
> z/OS 2.4 and Cobol 6.3,pretty vanilla.  I've read through SDB explanations
> in several manuals but haven't found the explanation as to why this is
> happening.
>
> We have a Cobol program with record length 200, and the developer
> inadvertently omitted the BLOCK CONTAINS 0 RECORDS  clause which according
> to the Cobol manual says the file is supposed to be unblocked.  Developer
> runs the program in batch using a DD card like this for the unblocked
> dataset.
>
> //VSF  DD DSN=TEST.DATASET.NAME,
> //DISP=(NEW,CATLG,DELETE),
> //*   UNIT=VTS,
> //UNIT=SYSDA,
> //SPACE=(CYL,(5,20),RLSE),
> //DCB=MDCB.TEST.DATASET.NAME
>
> The only DCB information provided is in the MDCB statement which looks
> like this:
>
>  % XT Device  Dsorg Recfm Lrecl Blksz
> --
> MDCB.TEST.DATASET.NAME
>   0   ? 0 3390  FB  200 0
>
> Sorry for the lack of formatting, BLKSIZE=0, LRECL=200, RECFM=FB.
>
> If he runs his job with the DD card as above, going to an SMS managed
> dataset, he gets half track blocking.  If he runs it changing it to
> UNIT=VTS, he gets an unblocked dataset, and if he runs it against DASD with
> an unmanaged dataset name, he also gets it unblocked.  Definitely makes it
> look like something in the SMS configuration, however, our SMS dataclas
> that this dataset falls under does not specify to use SDB that I could
> find.  So my questions are how to explain what's happening here?  Why does
> the MDCB specification of SDB seem to override the Cobol program in the
> case of the SMS managed dataset but the Cobol program overrides the MDCB
> for the non-SMS datasets?
>
> TIA,
>
> Rex
>
> --
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged. If the reader of this message is
> not the intended recipient or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any disclosure, distribution, copying, or any action taken or action
> omitted in reliance on it, is strictly prohibited and may be unlawful. If
> you have received this communication in error, please notify us immediately
> by replying to this message and destroy the material in its entirety,
> whether in electronic or hard copy format. Thank you.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: RIsks of sharing FICON adapters between LPARs on the same host

[Seymour J Metz]

For conventional devices, the application constructs a channel program, either 
directly or via an access method. The application, either directly or via an 
access method, uses STARTIO to initiate the I/O, and it is ther STASRTIO 
service that actually does the Start Subchannel (SSCH) instruction.

EXCP and EXCPVR are supported access methods, and with them the application is 
responsible for constructing the CCWs.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Laurence Chiu [lch...@gmail.com]
Sent: Wednesday, June 15, 2022 1:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RIsks of sharing FICON adapters between LPARs on the same host

Thanks. That sounds like a really good explanation to me.  From way distant
memory as each LPAR initiates an I/O eventually a CCW must be created
though these days I can't imagine any application program worrying about
that.  Something you might do in Assembler even though you would probably
invoke a MACRO.

It was an academic debate and I doubt if I would raise it with the security
team :-(

On Wed, Jun 15, 2022 at 3:02 PM Ken Bloom  wrote:

> The risk is not with the ficon channels as the way CCW’s are sequenced it
> would be virtually impossible for info to bleed across lpar’s.  Since Dasd
> is now virtual in all systems (IBM, EMC, Visara ,Hitachi) there is a
> greater chance of the shared file system causing data to be “misplaced”.
> Even so, it’s highly unlikely.
>
> Kenneth A. Bloom
> CEO
> Avenir Technologies Inc
> /d/b/a Visara International
> 203-984-2235
> bl...@visara.com
> http://secure-web.cisco.com/1UNCxtp1BQi2jN7M3ossMR_pNHB_6xoh8tXOLHS6w_9p89kwm5ihrgk2nJBpH5bs-MWC2X4aYc30i5SAomma7jusnrjy2FuNKEJEtdg2OBkOimIi_QG-t-WRZVfs9Y0zDFSa28Q5_4kouOVEiuTEYvmzk9tOMTYSSDPqtjU6asdrWfQHeotNuXO5klq31Fh1O9jcUEfq4HOo_4r8QzHauncukFh4o4Ab2LYayVk39cs4clZASm8UDnkumhQ0vFAoEMMrc7U3EWKWI45fG8cRXhWNpvACj6HQuqLqdtt4DtXLTjAVBjr3ZJhCQoyB9f8IKfUwNZvaEZ9hg0gxMysd2vVHUOvzAhQwv25lTNQ7KP3ya6AmzJ1C6i80xgaORJZJSng2S94znoPfZnakchu-cL8B0pHEy0BmGKjwxPQ0vog0FsF7c1sJMlLr_tOHGyBDM/http%3A%2F%2Fwww.visara.com
>
>
> On Jun 14, 2022, at 10:38 PM, Mike Schwab  wrote:
>
> z/VM can share PCHPIDs.  But we always had 4 FICON for every LPAR for
> DASD.
>
> On Tue, Jun 14, 2022 at 9:07 PM Laurence Chiu  wrote:
>
> We had an interesting question raised recently in my work place by our
> security team.
>
> They said, if you have multiple LPARs on a Z box and you share FICON
> adapters going to the same DS8K is there any data leak issue that could
> occur? That is,  could LPAR1 inadvertently see traffic to the SAN that is
> defined for LPAR2 but sharing the same FICON adapter. Maybe somebody mixed
> up the IODF or something like that?
>
> I thought not and said, isn't that how VMware and Hiper-V work. The
> hypervisors share out FC cards etc. to the various VM's and it doesn't seem
> to be an issue and z/OS (or is PR/SM) is likely to be a much hardier OS
> security wise.
>
> Anyway I would get the view of the experts on the forum.
>
> 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: SFTP JOB Data parameter

[Seymour J Metz]

Write a REXX script to do the file transfer. You can use the date('S') function 
to generate the date in the format mmdd, then parse out the component to 
build your dsn.


See Chapter 12. FTP Client Application Programming Interface (API), p. 307, in 
z/OS Communications Server 2.5 IP Programmer's Guide and Reference, 
SC27-3659-50.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
saurabh khandelwal [sourabhkhandelwal...@gmail.com]
Sent: Wednesday, June 15, 2022 6:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SFTP JOB Data parameter

--


Dear All,



I am am running below Job in TSO env and getting to get file file from
windows to Mainframe env.



Initially file was static and all worked well. But now, requirement is to
get the file, which has current time stamp on daily basis.



Ex : EBC-GOV-mmdd.txt'   in this mmdd should be replace with
year/month/date.



But I am unable to find way to achieve this goal. Can you please help on
this issue.





//SFTPSEBC JOB (7330),MSGCLASS=X,CLASS=P,NOTIFY=

//STEP1   EXEC PGM=IKJEFT01,REGION=0M

//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC

//SYSTSIN   DD DSN=NP.LIB.CLIST(SFTPSEBC),DISP=SHR

//OUTPUT DD SYSOUT=*

//SYSTSPRT DD SYSOUT=*

/*







EDIT   NP.LIB.CLIST(SFTPSEBB) - 01.01Columns 1
00072

Command ===>  Scroll ===>
CSR

07  OSHELL { echo 'lcd /u/op117/';
+

08   echo 'cd /FRB/EBCClearing/Staging/tmp';
+

09   echo 'ASCII';
+

10   echo 'get EBC-GOV-mmdd.txt'; } | +

11 sftp -P  eftmfge...@10.222.xx.xx


12 OGET '/u/op117/EBC-GOV-mmdd.txt'  -

13   'NBFDP.DATA.XX.XX.SFTP'

**  Bottom of Data


--
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: SFTP JOB Data parameter

[saurabh khandelwal]

Hello Paul,

Thank for reply but system doesn't take %D as date variable.  It taking as
file name. So variable in file mmdd not getting replaced with actual
date

On Wed, Jun 15, 2022, 15:54 Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 15 Jun 2022 13:44:43 +0300, saurabh khandelwal  wrote:
> >
> >I am am running below Job in TSO env and getting to get file file from
> >windows to Mainframe env.
> >
> >Initially file was static and all worked well. But now, requirement is to
> >get the file, which has current time stamp on daily basis.
> >
> >Ex : EBC-GOV-mmdd.txt'   in this mmdd should be replace with
> >year/month/date.
> >
> # Change:
> echo 'get EBC-GOV-mmdd.txt'
>
> # to
> date '+get EBC-GOV-%D.txt'
>
> >
> >But I am unable to find way to achieve this goal. Can you please help on
> >this issue.
> >
> >//SFTPSEBC JOB (7330),MSGCLASS=X,CLASS=P,NOTIFY=
> >//STEP1   EXEC PGM=IKJEFT01,REGION=0M
> >//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC
> >//SYSTSIN   DD DSN=NP.LIB.CLIST(SFTPSEBC),DISP=SHR
> >//OUTPUT DD SYSOUT=*
> >//SYSTSPRT DD SYSOUT=*
> >/*
> >
> >EDIT   NP.LIB.CLIST(SFTPSEBB) - 01.01Columns 1
> >00072
> >
> >Command ===>  Scroll ===>
> >CSR
> >
> >07  OSHELL { echo 'lcd /u/op117/';
> >+
> >
> >08   echo 'cd /FRB/EBCClearing/Staging/tmp';
> >+
> >
> >09   echo 'ASCII';
> >+
> >
> >10   echo 'get EBC-GOV-mmdd.txt'; } | +
> >
> >11 sftp -P  eftmfge...@10.222.xx.xx
> >
> >
> >12 OGET '/u/op117/EBC-GOV-mmdd.txt'  -
> >
> >13   'NBFDP.DATA.XX.XX.SFTP'
> >
> >**  Bottom of Data
> >
>
> --
> 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: SFTP JOB Data parameter

[Paul Gilmartin]

On Wed, 15 Jun 2022 13:44:43 +0300, saurabh khandelwal  wrote:
>
>I am am running below Job in TSO env and getting to get file file from
>windows to Mainframe env.
>
>Initially file was static and all worked well. But now, requirement is to
>get the file, which has current time stamp on daily basis.
>
>Ex : EBC-GOV-mmdd.txt'   in this mmdd should be replace with
>year/month/date.
>
# Change:
echo 'get EBC-GOV-mmdd.txt'

# to
date '+get EBC-GOV-%D.txt'

>
>But I am unable to find way to achieve this goal. Can you please help on
>this issue.
>
>//SFTPSEBC JOB (7330),MSGCLASS=X,CLASS=P,NOTIFY=
>//STEP1   EXEC PGM=IKJEFT01,REGION=0M
>//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC
>//SYSTSIN   DD DSN=NP.LIB.CLIST(SFTPSEBC),DISP=SHR
>//OUTPUT DD SYSOUT=*
>//SYSTSPRT DD SYSOUT=*
>/*
>
>EDIT   NP.LIB.CLIST(SFTPSEBB) - 01.01Columns 1
>00072
>
>Command ===>  Scroll ===>
>CSR
>
>07  OSHELL { echo 'lcd /u/op117/';
>+
>
>08   echo 'cd /FRB/EBCClearing/Staging/tmp';
>+
>
>09   echo 'ASCII';
>+
>
>10   echo 'get EBC-GOV-mmdd.txt'; } | +
>
>11 sftp -P  eftmfge...@10.222.xx.xx
>
>
>12 OGET '/u/op117/EBC-GOV-mmdd.txt'  -
>
>13   'NBFDP.DATA.XX.XX.SFTP'
>
>**  Bottom of Data
>

-- 
gil

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

Re: IBM Semeru Runtime 11.0.15.0 for z/OS Now Available [Internal]

[Usher, Darrold]

Thanks very much. Is there a Semeru Program product support website where I can 
track developments? 

Classification: Internal



Disclaimer: This email and any attachments are the property of USAA and may 
contain confidential and/or privileged material. If you are not the intended 
recipient, any use, disclosure or copying of this email or any attachments is 
unauthorized. If you received this email in error, please immediately notify 
the sender and delete the email and any attachments from your computer.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Timothy Sipples
Sent: Wednesday, June 15, 2022 1:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: IBM Semeru Runtime 11.0.15.0 for z/OS Now Available 
[Internal]

Darrold Usher wrote:
>Can CICS, IMS, z/OS Connect, z/OSMF leverage IBM Semeru Runtime 
>https://urldefense.com/v3/__http://11.0.15.0__;!!GryZGb6B1VCs0SfC!UY5hrlIhs-gMezKJGsDaYQt4WoCHR-CzbkI0bo0OlZv1N61vNfR_yDi_SOPc0O7d$
>  for their JVMs?

Let's take these in order:

1. CICS: Yes, with CICS Transaction Server 6.1 for z/OS. Expected General 
Availability of CICS TS 6.1 is this Friday, June 17, 2022.

2. IMS: I assume you're asking about JMP and JBP regions. In the pipeline I 
believe, but I have no inside information. However, you should already be able 
to do certain important things with IMS from Semeru VMs such as connect to IMS 
DB via JDBC.

3. z/OS Connect: The latest release (3.0.57) uses embedded Liberty 
https://urldefense.com/v3/__http://22.0.0.4__;!!GryZGb6B1VCs0SfC!UY5hrlIhs-gMezKJGsDaYQt4WoCHR-CzbkI0bo0OlZv1N61vNfR_yDi_SP6sFzeE$
 . This release of Liberty is supported on the IBM Semeru Runtime. However, I 
don't think IBM has quite connected the dots yet back to z/OS Connect since 
it's not necessarily only a lift and shift at the application level due to 
possible deprecations (see below).

4. z/OSMF: In the pipeline I believe, but I have no inside information.

#3 and #4 are somewhat less exciting since they're used as embedded runtimes, 
and IBM supports the runtimes on IBM's lifecycle. OpenJDK 11/Semeru 11 have 
deprecations compared to Java 8, and those have to be checked. In particular 
the security implementation changes. #1 and #2 are arguably the more 
interesting/urgent ones since those are directly programmed environments.

- - - - -
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity IBM zSystems/LinuxONE, 
Asia-Pacific 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

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

SFTP JOB Data parameter

[saurabh khandelwal]

--


Dear All,



I am am running below Job in TSO env and getting to get file file from
windows to Mainframe env.



Initially file was static and all worked well. But now, requirement is to
get the file, which has current time stamp on daily basis.



Ex : EBC-GOV-mmdd.txt'   in this mmdd should be replace with
year/month/date.



But I am unable to find way to achieve this goal. Can you please help on
this issue.





//SFTPSEBC JOB (7330),MSGCLASS=X,CLASS=P,NOTIFY=

//STEP1   EXEC PGM=IKJEFT01,REGION=0M

//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC

//SYSTSIN   DD DSN=NP.LIB.CLIST(SFTPSEBC),DISP=SHR

//OUTPUT DD SYSOUT=*

//SYSTSPRT DD SYSOUT=*

/*







EDIT   NP.LIB.CLIST(SFTPSEBB) - 01.01Columns 1
00072

Command ===>  Scroll ===>
CSR

07  OSHELL { echo 'lcd /u/op117/';
+

08   echo 'cd /FRB/EBCClearing/Staging/tmp';
+

09   echo 'ASCII';
+

10   echo 'get EBC-GOV-mmdd.txt'; } | +

11 sftp -P  eftmfge...@10.222.xx.xx


12 OGET '/u/op117/EBC-GOV-mmdd.txt'  -

13   'NBFDP.DATA.XX.XX.SFTP'

**  Bottom of Data


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

Re: RIsks of sharing FICON adapters between LPARs on the same host

[Lennie Dymoke-Bradshaw]

It may be worth looking at the Common Criteria certifications for z/OS and/or 
PR/SM.

>From memory, the certifications for LPAR security separation required that 
>distinct LPARs in distinct security zones used separate devices. This included 
>(and hence outlawed) the sharing of DASD devices (such as entire DS8xxx) and 
>the sharing of Channel paths. 

The Certification Reports and the Security Targets are available here,
https://www.commoncriteriaportal.org/products/ 

The most current ones I could see were for z/OS 2.4 and for the IBM z15.
There is also one for z/VM 7.2.

I stress that I have not read these latest reports and I am working on 
knowledge of earlier version of z/OS and PR/SM.

Lennie Dymoke-Bradshaw
https://rsclweb.com 
‘Dance like no one is watching. Encrypt like everyone is.’


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Laurence Chiu
Sent: 15 June 2022 03:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RIsks of sharing FICON adapters between LPARs on the same host

We had an interesting question raised recently in my work place by our security 
team.

They said, if you have multiple LPARs on a Z box and you share FICON adapters 
going to the same DS8K is there any data leak issue that could occur? That is,  
could LPAR1 inadvertently see traffic to the SAN that is defined for LPAR2 but 
sharing the same FICON adapter. Maybe somebody mixed up the IODF or something 
like that?

I thought not and said, isn't that how VMware and Hiper-V work. The hypervisors 
share out FC cards etc. to the various VM's and it doesn't seem to be an issue 
and z/OS (or is PR/SM) is likely to be a much hardier OS security wise.

Anyway I would get the view of the experts on the forum.

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: IBM Semeru Runtime 11.0.15.0 for z/OS Now Available [Internal]

[Timothy Sipples]

Darrold Usher wrote:
>Can CICS, IMS, z/OS Connect, z/OSMF leverage IBM Semeru
>Runtime 11.0.15.0 for their JVMs?

Let’s take these in order:

1. CICS: Yes, with CICS Transaction Server 6.1 for z/OS. Expected General 
Availability of CICS TS 6.1 is this Friday, June 17, 2022.

2. IMS: I assume you’re asking about JMP and JBP regions. In the pipeline I 
believe, but I have no inside information. However, you should already be able 
to do certain important things with IMS from Semeru VMs such as connect to IMS 
DB via JDBC.

3. z/OS Connect: The latest release (3.0.57) uses embedded Liberty 22.0.0.4. 
This release of Liberty is supported on the IBM Semeru Runtime. However, I 
don’t think IBM has quite connected the dots yet back to z/OS Connect since 
it’s not necessarily only a lift and shift at the application level due to 
possible deprecations (see below).

4. z/OSMF: In the pipeline I believe, but I have no inside information.

#3 and #4 are somewhat less exciting since they’re used as embedded runtimes, 
and IBM supports the runtimes on IBM’s lifecycle. OpenJDK 11/Semeru 11 have 
deprecations compared to Java 8, and those have to be checked. In particular 
the security implementation changes. #1 and #2 are arguably the more 
interesting/urgent ones since those are directly programmed environments.

— — — — —
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM zSystems/LinuxONE, Asia-Pacific
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: FTP Software for Mainframe to PC

[Bernd Oppolzer]

Could the error be the comma?
Isn't there a facility to define a character as a separator for multiple 
commands in one line,

and could it be that the comma was this separator in the OP's environment?

Regards,
Bernd


Am 15.06.2022 um 07:08 schrieb Tom Brennan:
Is he talking about an Edit command?  I just tried this and I didn't 
get any error message:


Command ===> CHANGE PARM '"Hello," says O''Reilly.'
** * Top of Data *
000100 This is a PARM
**  Bottom of Data ***

Command ===>
** * Top of Data *
000100 This is a "Hello," says O''Reilly.
**  Bottom of Data ***

Then I'd just CHANGE "O''Reilly" "O'Reilly"

Come to think of it, I've probably issued something like the command 
above many times to change double ticks to single, so I like the way 
it works today.


On 6/14/2022 9:35 PM, Jeremy Nicoll wrote:

On Tue, 14 Jun 2022, at 17:45, Paul Gilmartin wrote:


ISPF, like JCL, is a user interface supporting delimited strings in
commands,  but reports
an error for:
 CHANGE PARM '"Hello," says O''Reilly.'


Does the error say what the problem is?


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