Re: Assembler calling DSNTAIR

[Tom Marchant]

On Fri, 13 Apr 2018 15:23:04 +, Seymour J Metz wrote:

>What format save area does R13 point to?

ITYM how big of a save area does R13 point to when he makes the 
call. A save area does not have a format until a program saves its 
caller's registers in it according to some format.

-- 
Tom Marchant

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

Re: Assembler calling DSNTAIR

[Tom Marchant]

On Fri, 13 Apr 2018 14:24:19 +, Ward Able, Grant wrote:

>I have an Assembler program linked AMODE(31) RMODE(24). It makes SQL calls and 
>under some circumstances I will call DSNTIAR to printout the DB2 error & 
>diagnostic info.
>The call statement I am using for this is:
>
>CALL DSNTIAR,(SQLCA,(6),LRECL),LINKINST=BASSM,MF=(E,PARM)

The CALL will generate a V(DSNTIAR). LINKINST=BASSM will cause the 
call to generate BASSM to transfer control to that address. The VCON 
will (IIRC) have bit 0 set to zero, so you will be calling the program in 
AMODE 24. Does DSNTIAR require that? Is your save area located below 
the line?
>
>Yet I am getting an S0C4 abend in DSNTIAR. I thought that using LINKINST=BASSM 
>would have resolved this for me.

Resolved what? Does DSNTIAR use BSM to return?

-- 
Tom Marchant

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

Re: Assembler calling DSNTAIR

[Ward Able, Grant]

Thanks for the response Shmuel.
COMPLETION CODE  SYSTEM = 0C4  REASON CODE = 0004

I am usually a CICS programmer, so batch abends are slightly foreign to me.
My own program's savearea is addressed by R13. What format? Heck I don't know! 
The DSECT starts with DS 18F, if that helps.
DSNTIAR is linked into my loadmod.

It seems as if I need a serious batch dump debugging refresher!


Regards - Grant.

In theory, there's no difference between theory and practice. In practice, 
there is.

There is no such thing as the Cloud. It is just somebody else's computer.

If you don't have time to do it right, when will you have the time to do it 
over? - John Wooden


DTCC Internal (Green)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: 13 April 2018 16:23
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler calling DSNTAIR

ATTENTION! This email originated outside of DTCC; exercise caution.


What format save area does R13 point to? Is DSNTIAR linked with you or are you 
doing a LOAD? What is the reason code for the 0C4 (I hate the overloading!)? 
Have you looked at the failing code?


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


From: IBM Mainframe Discussion List  on behalf of 
Ward Able, Grant 
Sent: Friday, April 13, 2018 10:24 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Assembler calling DSNTAIR

I have an Assembler program linked AMODE(31) RMODE(24). It makes SQL calls and 
under some circumstances I will call DSNTIAR to printout the DB2 error & 
diagnostic info.
The call statement I am using for this is:

CALL  DSNTIAR,(SQLCA,(6),LRECL),LINKINST=BASSM,MF=(E,PARM)

Yet I am getting an S0C4 abend in DSNTIAR. I thought that using LINKINST=BASSM 
would have resolved this for me.
Any hints or clues about this?



Regards - Grant.

In theory, there's no difference between theory and practice. In practice, 
there is.

There is no such thing as the Cloud. It is just somebody else's computer.

If you don't have time to do it right, when will you have the time to do it 
over? - John Wooden


DTCC Internal (Green)
DTCC DISCLAIMER: This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error, please notify us 
immediately and delete the email and any attachments from your system. The 
recipient should check this email and any attachments for the presence of 
viruses.  The company accepts no liability for any damage caused by any virus 
transmitted by this email.


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

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DTCC DISCLAIMER: This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error, please notify us 
immediately and delete the email and any attachments from your system. The 
recipient should check this email and any attachments for the presence of 
viruses.  The company accepts no liability for any damage caused by any virus 
transmitted by this email.

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

Re: Assembler calling DSNTAIR

[Seymour J Metz]

What format save area does R13 point to? Is DSNTIAR linked with you or are you 
doing a LOAD? What is the reason code for the 0C4 (I hate the overloading!)? 
Have you looked at the failing code?


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


From: IBM Mainframe Discussion List  on behalf of 
Ward Able, Grant 
Sent: Friday, April 13, 2018 10:24 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Assembler calling DSNTAIR

I have an Assembler program linked AMODE(31) RMODE(24). It makes SQL calls and 
under some circumstances I will call DSNTIAR to printout the DB2 error & 
diagnostic info.
The call statement I am using for this is:

CALL  DSNTIAR,(SQLCA,(6),LRECL),LINKINST=BASSM,MF=(E,PARM)

Yet I am getting an S0C4 abend in DSNTIAR. I thought that using LINKINST=BASSM 
would have resolved this for me.
Any hints or clues about this?



Regards – Grant.

In theory, there's no difference between theory and practice. In practice, 
there is.

There is no such thing as the Cloud. It is just somebody else’s computer.

If you don't have time to do it right, when will you have the time to do it 
over? - John Wooden


DTCC Internal (Green)
DTCC DISCLAIMER: This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error, please notify us 
immediately and delete the email and any attachments from your system. The 
recipient should check this email and any attachments for the presence of 
viruses.  The company accepts no liability for any damage caused by any virus 
transmitted by this email.


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

Assembler calling DSNTAIR

[Ward Able, Grant]

I have an Assembler program linked AMODE(31) RMODE(24). It makes SQL calls and 
under some circumstances I will call DSNTIAR to printout the DB2 error & 
diagnostic info.
The call statement I am using for this is:

CALL  DSNTIAR,(SQLCA,(6),LRECL),LINKINST=BASSM,MF=(E,PARM)

Yet I am getting an S0C4 abend in DSNTIAR. I thought that using LINKINST=BASSM 
would have resolved this for me.
Any hints or clues about this?



Regards – Grant.

In theory, there's no difference between theory and practice. In practice, 
there is.

There is no such thing as the Cloud. It is just somebody else’s computer.

If you don't have time to do it right, when will you have the time to do it 
over? - John Wooden


DTCC Internal (Green)
DTCC DISCLAIMER: This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error, please notify us 
immediately and delete the email and any attachments from your system. The 
recipient should check this email and any attachments for the presence of 
viruses.  The company accepts no liability for any damage caused by any virus 
transmitted by this email.


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

Re: [EXTERNAL] Re: ISPF Application - a warning

[Elardus Engelbrecht]

Dyck, Lionel B. (TRA) wrote:

>That is exactly correct - never use a variable that begins with 'Z' when 
>coding an ISPF application.

This is documented in "z/OS ISPF Dialog Developer's Guide and Reference"



Note:  ISPF uses variable names that start with Z. Therefore, Z variables are 
reserved for ISPF system-related uses. User written dialogs must avoid creating 
or manipulating variable names that start with Z unless their use has been 
clearly documented.



Groete / Greetings
Elardus Engelbrecht

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

Re: [EXTERNAL] Re: ISPF Application - a warning

[Dyck, Lionel B. (TRA)]

That is exactly correct - never use a variable that begins with 'Z' when coding 
an ISPF application.

Something that I forgot :(

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer – RavenTek Solution Partners

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jeremy Nicoll
Sent: Friday, April 13, 2018 4:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: ISPF Application - a warning

On Thu, 12 Apr 2018, at 19:08, Dyck, Lionel B. (TRA) wrote:

> Thus PDSEGEN 5.3.1 fixes this and I know now never to have a variable 
> within any ISPF application of z.

I have a feeling that one is meant to avoid any variable name that starts with 
Z too... so no "ZERO" or "ZORRO" or...

--
Jeremy Nicoll - my opinions are my own.

--
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: Filemanager and security

[Robert S. Hansel (RSH)]

Hi Rex,

How have you activated tape protection in your environment - SETROPTS, 
PARMLIB(DEVSUPxx), or a Tape Management product option? What Tape Management 
product do you have?

Not that this may matter, but does your ID have READ access to FACILITY ICHBLP 
or your Tape Management product's equivalent? If it does, have you tried the 
function with an ID that does not have this access?

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc. *** Celebrating our 25th Year ***
617-969-8211
www.linkedin.com/in/roberthansel
https://twitter.com/RSH_RACF
www.rshconsulting.com

-Original Message-
Date:Thu, 12 Apr 2018 13:08:16 +
From:"Pommier, Rex" 
Subject: Re: [External] Re: Filemanager and security

Hi Kolusu,

Unfortunately that doesn't do it.  According to the FileManager documentation - 
which I verified on my system - granting any kind of access (read, update, 
alter, it doesn't matter) either grants you access to the function or denies it 
(access=none).  For example, if I grant READ access to FILEM.TAPE.OUTPUT, I 
have access to update tapes.  Likewise if I grant ALTER access to 
FILEM.TAPE.INPUT, all that gives me access to is tape browse type functions 
like tape browse and tape label display.  These are just toggles to the 
function within FileManager.  The problem that I am running into is that for 
example, if I have 2 production datasets on tape, one with GL information and 
the other with the payroll information on it, and I need to grant an accountant 
access to the GL information but not the payroll, it appears that I can't.  It 
looks like FileManager doesn't check dataset level access.  Once I grant access 
to FILEM.TAPE.INPUT, a user can browse data on any tape on the system, 
regardless of whether they have access at a dataset level or not.  

I'm hoping I just have something set wrong, but I can't seem to get FileManager 
to look at dataset level RACF protection on tapes.  As I mentioned earlier, I 
have a mixed GDG, with some generations on disk and others on tape.  If I grant 
an ID access to the TB function, whether through FILEM.FUNCTION.TB or through 
the grouping profile FILEM.TAPE.INPUT, I can look at the data on the tape, even 
though I can't look at the other generation that's on disk through FileManager. 
 

Test I just reran this morning.  GDG with 5 generations, 4 on disk, 1 on tape.  

ISPF edit on one of the disk based generations I got RACF security violation, 
ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )
Filemanager option 2 edit on the same generation as ISPF:  ACCESS INTENT(READ   
)  ACCESS ALLOWED(NONE   )
Filemanager option 4.1, Tape Browse: FILEM.FUNCTION.TB CL(FACILITY)ACCESS 
INTENT(READ   )  ACCESS ALLOWED(NONE   )
Change FILEM.FUNCTION.TB to give me READ access to the FACILITY profile
Filemanager option 4.1:  I got access to browse the data
Filemanager option 2 with the tape generation: I got access.

Looks like it's time for a question to IBM FM folks to see if this is WAD.  In 
my mind, this is a security hole.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sri h Kolusu
Sent: Monday, April 09, 2018 4:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Filemanager and security

Pommier Rex,

I believe you need to update the following functions


FILEM.TAPE.INPUT
Tape input functions
FILEM.TAPE.OUTPUT
Tape output functions
FILEM.TAPE.DUPLICATE
Tape copy functions
FILEM.TAPE.UPDATE
Tape update functions

If you are only allowing browse function of the tape dataset then you need
to do something like this


PERMIT FILEM.TAPE.INTPUT CLASS(FACILITY) ID(userid) ACCESS(READ)

Check this link which explains in detail about the function

https://www.ibm.com/support/knowledgecenter/en/SSXJAV_13.1.0/com.ibm.filemanager.doc_13.1/cust/secracf.html

Thanks,
Kolusu

IBM Mainframe Discussion List  wrote on
04/09/2018 12:10:19 PM:

> From: " SH19-8163-00, Rex" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 04/09/2018 12:11 PM
> Subject: Filemanager and security
> Sent by: IBM Mainframe Discussion List 
>
> Hello list,
>
> I've been poring through the FileManager manuals and either am
> missing something or it doesn't exist regarding security.  We're
> running FM 13.1 under ISPF so non-APF authorized.  I needed to grant
> the capability for browsing tape datasets to a developer.  I did
> this granting READ access to FILEM.FUNCTION.TB.  This granted the
> access to the tape browse function.  However, it appears that
> FileManager bypasses dataset name SAF checking if the user has
> access to the TB function.  To wit: a particular GDG has a mix of
> tape and disk generations.  I specifically denied access to this GDG
> to my ID.  I get a RACF violation when trying to browse the disk
> based generation, but FileManager allows me to use 

Re: ISPF Application - a warning

[Jeremy Nicoll]

On Thu, 12 Apr 2018, at 19:08, Dyck, Lionel B. (TRA) wrote:

> Thus PDSEGEN 5.3.1 fixes this and I know now never to have a variable 
> within any ISPF application of z.

I have a feeling that one is meant to avoid any variable name 
that starts with Z too... so no "ZERO" or "ZORRO" or...

-- 
Jeremy Nicoll - my opinions are my own.

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