Re: ISPF storage protection
On 3/3/2014 4:52 PM, dpewen wrote: Yes ... SPKA requires SUP state SPKA works in problem state if the PKM allows it. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beta92 help
Try this job to get the archive expiration date of jobs:
//BQL EXEC PGM=BST01RFF,REGION=0M,
// PARM=('S=92,B01LST=nn,B92LST=nn',
// 'PGM=BST05CMD,SIGNON=YES')
//*
//STEPLIB DD DISP=SHR,
// DSN=BSA.LOAD
// DD DISP=SHR,
// DSN=BETA92.LOAD
//*
//SFFPARM DD DISP=SHR,
// DSN=BETA.PARMLIB
//*
//B92DEF DD DISP=SHR,
// DSN=BETA92.DEF.DATA
//*
//BQLINDD *
SELECT TABLE GAR FIELDS(SRCJOBN SRCJOBI SRCSUBD SRCSUBT GAREXPDT) -
GENFILE(nn)
- your garfile number
//*
//SFFFDUMP DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//*
//BQLPROT DD SYSOUT=*,DCB=(DSORG=PS,LRECL=255,RECFM=VB)
-search results
//BQLPRINT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf
Of Klimek, Albert
Sent: Friday, February 28, 2014 10:28 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Beta92 help
I am looking for a way to determine the archive expiration date of jobs in
beta92 archives. I think that is only possible with an RPG report.
Unfortunately I have not found the necessary information in the Beta92 Database
Dictionary. can someone help me
Thanks Albert
VERLAGSGRUPPE WELTBILD GMBH
Sitz der Gesellschaft: Augsburg
Handelsregister Augsburg HRB 6035
Ust-ID-Nr: DE 127501299
Geschäftsführung:
Carel Halff (Vorsitzender), Dr. Martin Beer, Josef Schultheis
Vorsitzender des Aufsichtsrats:
Generalvikar DDr. Peter Beer
--
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: ISPF storage protection
Douglas Do you have a server address space for your product? If so, can I suggest that perhaps a re-design would be beneficial here to remove any requirement for the client caller to be running in non-problem state : (1) Have your server setup a system-LX and ETDEF a space-switch PC routine (2) Your server creates a cell pool of request block elements in the required key (if you are using key-7 (Db2) then the easiest way is for your server to execute in key-7 using a definition in SCHEDxx) (3) The client caller then has some sort of macro interface to the PC-ss (4) The PC-ss routine gets a cell from the server key-7 private and populates it (5) The PC-ss routine adds the new request block to the server queue (6) Another task in the server address space processes the queue and releases the request cell back when done Notes : (o) MVCDK and MVCSK can be used to copy data to and from the server (running in Key7) to your client caller (running in whatever key) (o) If you require a synchronous response, then the PC-ss could SUSPEND the caller and then the request processing task can then RESUME him when done with the request (o) Task level resource managers are very useful to handle caller gone situations when sync response is required - (see RESMGR macro) (o) You may wish to SAF protect the logic in the PC-ss so that only authorized users can add to the queue. Using the above technique, there is no requirement for the client to be running in a non-problem state. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Douglas P Ewen Sent: 03 March 2014 23:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: ISPF storage protection Hello, I have a product that uses ISPF panels to allow the user to specify control information for the product. This control information is turned into a control block and then passed(XCTL) to a program that attempts to add the control block to a queue which resides in storage key=7. Although I have APF authorized the program that tries to update the que, I cannot get into a key=7 using the MODESET SVC. The MODESET SVC fails with system completion code=047. Is there anyway to allow a program to successfully issue the MODESET SVC under ISPF? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS WIKI access from a mianframe (TSO)
Gotcha, missed that part of the requirement. I will however say that the wiki pages are readable text files. So one could go read the Unix filesystem directly if you knew the files you were asking for. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, March 03, 2014 4:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS WIKI access from a mianframe (TSO) On 2014-03-03 13:30, Jousma, David wrote: We run it. Accessed via Web browser. Yes, but is that Web browser runing on the mainframe? If not, how is this considered access from a mianframe? I suppose this depends on the sense of the ambiguous prepositional adverb from, left ambiguous by the OP. Either: I can view the Orion Nebula from my back yard, or: Observing in my backyard, I can view light from the Orion Nebula. Likwise: I can view a WIKI as I work from a mainframe, or: Viewing elsewhere, I can view a WIKI served by a mainframe. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Does this use a 327x as a display, or operate as an X11 client with your choice of server on desktop? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
It's.all a catch 22 as you need to authorized to create PC rtn's Sent from my iPhone On Mar 4, 2014, at 3:32 AM, Ed Jaffe edja...@phoenixsoftware.com wrote: On 3/3/2014 4:52 PM, dpewen wrote: Yes ... SPKA requires SUP state SPKA works in problem state if the PKM allows it. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.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
Re: ISPF storage protection
Obviously the *server* code that owns the PC routines must run in an authorized environment - however the important thing here is that the *client* code runs in problem state. Using a PC-ss to add requests to a server ASID to perform the authorized function on behalf of the caller means that : (1) No updates required to IKJTSOxx (2) No MODESET in client code (3) Client code can run in non-authorized state in non-TSO environments (4) System integrity exposures are reduced Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Micheal Butz Sent: 04 March 2014 12:55 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection It's.all a catch 22 as you need to authorized to create PC rtn's Sent from my iPhone On Mar 4, 2014, at 3:32 AM, Ed Jaffe edja...@phoenixsoftware.com wrote: On 3/3/2014 4:52 PM, dpewen wrote: Yes ... SPKA requires SUP state SPKA works in problem state if the PKM allows it. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IMS DB Segment modification
Hello. We IMS DB in this we are planning to drop one of the fields from one segment which is having 2 bytes and expand the adjacant field from the current 2 bytes to 4 bytes. We are modifying the programs for this, so kindly let someone let me know what things we need to take care for the modified version of DB to be implemented in production? Thanks Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Disabled wait
The reason I can't open a PMR is political so I won't discuss that, we'll just leave it at I can't. But through some slow application of maintenance I determined the 2 that PTFs that cause the DW are UA69565 and UA71730. I've no idea why they cause an issue, but when I apply them I get the DW. To make it even more odd is those PTFs are applied to other z/OS 1.13 systems I run. On Fri, Feb 28, 2014 at 4:34 PM, Tom Marchant m42tom-ibmm...@yahoo.comwrote: On Fri, 28 Feb 2014 16:16:54 -0500, Mark Pace pacemainl...@gmail.com wrote: I've decided to fall back to pre-maintenance and reapply just a few at a time to see if I can determine which caused the DW. Why not open a PMR and have IBM look at the dump? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The postings on this site are my own and don't necessarily represent Mainline's positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OCOPY fails to convert text
In 5223415504632809.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 05:07 PM, Paul Gilmartin paulgboul...@aim.com said: But, is there a convenient alternative collective term designating those 8-bit character sets in which 'A' is 0x41; '0' is 0x30, etc.? Perhaps Shmuel can, in a more constructive mode, suggest one. Does ISO Latin include ISO8859-x No; there are ISO 8859-x code pages for non-Latin alphabets, e.g., Hebrew. Those include all of the letters needed for English, but are missing the accented letters needed for, e.g., French. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
In 9111247477380775.wa.dpewenbellsouth@listserv.ua.edu, on 03/03/2014 at 05:51 PM, Douglas P Ewen dpe...@bellsouth.net said: Although I have APF authorized the program that tries to update the que (sic) How? Is there anyway to allow a program to successfully issue the MODESET SVC under ISPF? Yes. Before doing that, have you considered setting up a PC interface for adding elements to the queue? ISPF is subject to the same rules as any other TSO application; in order to run authorized code, it has to use the relevant TSO services. The easiest way is to package the code in a TSO command that is defined to TSO as authorised and to include an ISPMTCM macro for the command with the appropriate FLAG, e.g., FLAG=X'22'.. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
In 9819019940159674.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 06:14 PM, Paul Gilmartin paulgboul...@aim.com said: I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. Because it would be a major security breach. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
In 1393894348.42329.yahoomail...@web181502.mail.ne1.yahoo.com, on 03/03/2014 at 04:52 PM, dpewen dpe...@bellsouth.net said: Yes ... SPKA requires SUP state Actually, it's only semiprivileged. In problem state it can set any key enabled in the PSW-key mask. However, z/OS will not (I hope) dispatch an unauthorized program with key 7 enabled in the mask. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS WIKI access from a mianframe (TSO)
In 4ee2851a2279b94cb70cd69b17410609b7e7b...@s1flokydce2kx01.dm0001.info53.com, on 03/04/2014 at 12:09 PM, Jousma, David david.jou...@53.com said: I will however say that the wiki pages are readable text files. And not much harder to parse than HTML. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Disabled wait
UA69565 closes APAR OA42179 UA71730 closes APAR OA43690 As of a few minutes ago, neither PTF was indicated as a PE. I checked the cover letters for the z/OS 2.1 versions of those PTF's (UA69566 and UA71731) and of the 2 I would consider UA71730 the most likely culprit. I would check you apply run for failures during the application of these PTF's, or bypass of a pre -req. Can you post the SMPOUT from your apply run? I can't think of anything else that would cause this. snip But through some slow application of maintenance I determined the 2 that PTFs that cause the DW are UA69565 and UA71730. I've no idea why they cause an issue, but when I apply them I get the DW. To make it even more odd is those PTFs are applied to other z/OS 1.13 systems I run. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IMS DB Segment modification
Ron, If you have not done so, you might want to join the IMS List for this type of question. It will probably be a better place to ask http://imslistserv.bmc.com/SCRIPTS/WA-BMC.EXE?SUBED1=IMS-LA=1 When posting remember to include your level of IMS, z/OS Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ron Thomas Sent: Tuesday, March 04, 2014 6:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IMS DB Segment modification Hello. We IMS DB in this we are planning to drop one of the fields from one segment which is having 2 bytes and expand the adjacant field from the current 2 bytes to 4 bytes. We are modifying the programs for this, so kindly let someone let me know what things we need to take care for the modified version of DB to be implemented in production? Thanks Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Disabled wait
Once I get the last of the maintenance I am working on applied, I'll go back and try to apply these again looking for any irregularities with SYS1.NUCLEUS. On Tue, Mar 4, 2014 at 9:25 AM, Staller, Allan allan.stal...@kbmg.comwrote: UA69565 closes APAR OA42179 UA71730 closes APAR OA43690 As of a few minutes ago, neither PTF was indicated as a PE. I checked the cover letters for the z/OS 2.1 versions of those PTF's (UA69566 and UA71731) and of the 2 I would consider UA71730 the most likely culprit. I would check you apply run for failures during the application of these PTF's, or bypass of a pre -req. Can you post the SMPOUT from your apply run? I can't think of anything else that would cause this. snip But through some slow application of maintenance I determined the 2 that PTFs that cause the DW are UA69565 and UA71730. I've no idea why they cause an issue, but when I apply them I get the DW. To make it even more odd is those PTFs are applied to other z/OS 1.13 systems I run. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The postings on this site are my own and don't necessarily represent Mainline's positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
On Tue, 4 Mar 2014 08:54:43 -0500, Shmuel Metz (Seymour J.) wrote: In 9819019940159674.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 06:14 PM, Paul Gilmartin paulgboul...@aim.com said: I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. Because it would be a major security breach. That doesn't tell me much. Why? How? Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Disabled wait
You don't have SYS1.NUCLEUS allocated with secondary extents do you? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace Sent: Tuesday, March 04, 2014 9:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Disabled wait Once I get the last of the maintenance I am working on applied, I'll go back and try to apply these again looking for any irregularities with SYS1.NUCLEUS. On Tue, Mar 4, 2014 at 9:25 AM, Staller, Allan allan.stal...@kbmg.comwrote: UA69565 closes APAR OA42179 UA71730 closes APAR OA43690 As of a few minutes ago, neither PTF was indicated as a PE. I checked the cover letters for the z/OS 2.1 versions of those PTF's (UA69566 and UA71731) and of the 2 I would consider UA71730 the most likely culprit. I would check you apply run for failures during the application of these PTF's, or bypass of a pre -req. Can you post the SMPOUT from your apply run? I can't think of anything else that would cause this. snip But through some slow application of maintenance I determined the 2 that PTFs that cause the DW are UA69565 and UA71730. I've no idea why they cause an issue, but when I apply them I get the DW. To make it even more odd is those PTFs are applied to other z/OS 1.13 systems I run. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The postings on this site are my own and don't necessarily represent Mainline's positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Disabled wait
No, it's allocated exactly as it came from IBM. Data Set Name . . . : SYS1.NUCLEUS General Data Current Allocation Volume serial . . . : TRES13 Allocated blocks . : 1,072 Device type . . . . : 3390Allocated extents . : 1 Organization . . . : PO Maximum dir. blocks : 118 Record format . . . : U Record length . . . : 0 Block size . . . . : 32760 Current Utilization 1st extent blocks . : 1072Used blocks . . . . : 898 Secondary blocks . : 0 Used extents . . . : 1 Used dir. blocks . : 99 Number of members . : 578 Dates Creation date . . . : 2011/11/18 Referenced date . . : 2014/03/04 Expiration date . . : ***None*** On Tue, Mar 4, 2014 at 10:37 AM, Jousma, David david.jou...@53.com wrote: You don't have SYS1.NUCLEUS allocated with secondary extents do you? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace Sent: Tuesday, March 04, 2014 9:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Disabled wait Once I get the last of the maintenance I am working on applied, I'll go back and try to apply these again looking for any irregularities with SYS1.NUCLEUS. On Tue, Mar 4, 2014 at 9:25 AM, Staller, Allan allan.stal...@kbmg.com wrote: UA69565 closes APAR OA42179 UA71730 closes APAR OA43690 As of a few minutes ago, neither PTF was indicated as a PE. I checked the cover letters for the z/OS 2.1 versions of those PTF's (UA69566 and UA71731) and of the 2 I would consider UA71730 the most likely culprit. I would check you apply run for failures during the application of these PTF's, or bypass of a pre -req. Can you post the SMPOUT from your apply run? I can't think of anything else that would cause this. snip But through some slow application of maintenance I determined the 2 that PTFs that cause the DW are UA69565 and UA71730. I've no idea why they cause an issue, but when I apply them I get the DW. To make it even more odd is those PTFs are applied to other z/OS 1.13 systems I run. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The postings on this site are my own and don't necessarily represent Mainline's positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The postings on this site are my own and don't necessarily represent Mainline's positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
True, I have never understood that either, gil. It might more to do with executing the program in the appropriate TCB than a security exposure. Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, March 04, 2014 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection On Tue, 4 Mar 2014 08:54:43 -0500, Shmuel Metz (Seymour J.) wrote: In 9819019940159674.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 06:14 PM, Paul Gilmartin paulgboul...@aim.com said: I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. Because it would be a major security breach. That doesn't tell me much. Why? How? Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? -- 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: ISPF storage protection
It has to do with the fact that the APF code itself could become corrupted (if loaded into key-8 storage) by some user code running under a different TCB. Or that some key 8 storage area used by the APF code could be corrupted by user code running on a different TCB. This corruption could be either due to poor coding, or even a malicious attempt to get non-APF code running in APF mode. TSO has an interface, IKJEFTSR, which can run APF safely under TSO. But it does this my using a separate TCB structure to run the APF code and doing a STATUS STOP on all the other TCBs in the address space. Well, most of them, anyway. However, things running via IKJEFTSR cannot do ISPF functions for the very same reason. The ISPF code runs on a different TCB and that TCB is in a more or less hard wait. ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4b780/23.1 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4b780/23.1.2 On Tue, Mar 4, 2014 at 9:51 AM, Leonardo Vaz leonardo@cn.ca wrote: True, I have never understood that either, gil. It might more to do with executing the program in the appropriate TCB than a security exposure. Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, March 04, 2014 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection On Tue, 4 Mar 2014 08:54:43 -0500, Shmuel Metz (Seymour J.) wrote: In 9819019940159674.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 06:14 PM, Paul Gilmartin paulgboul...@aim.com said: I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. Because it would be a major security breach. That doesn't tell me much. Why? How? Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? -- 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 -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
The difference is that TSO (and ISPF) runs in problem state and the jobstep is unauthorized. In batch, when executing a program linked AC(1) that comes from a valid APF authorized library, then the entire jobstep is considered authorized. TSO must jump through a few hoops to attempt to provide a safe way of invoking the authorized program - this involves having a parallel authorized jobstep TMP task and suspending all TCBs on the non-authorized leg while the authorized code is executing. Hence the various tables in TSO (and ISPF) to define these special circumstance commands (or programs) that can run authorized. Throw into the ring, the confusion that can occur with TSOLIB and ISPLLIB (and STEPLIB) - it can get messy to code applications and debug problems in this area - especially when your code is running on other people's systems. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: 04 March 2014 15:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection True, I have never understood that either, gil. It might more to do with executing the program in the appropriate TCB than a security exposure. Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, March 04, 2014 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection On Tue, 4 Mar 2014 08:54:43 -0500, Shmuel Metz (Seymour J.) wrote: In 9819019940159674.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 06:14 PM, Paul Gilmartin paulgboul...@aim.com said: I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. Because it would be a major security breach. That doesn't tell me much. Why? How? Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? -- 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: z/OS WIKI access from a mianframe (TSO)
In 53150444.5030...@acm.org, on 03/03/2014 at 04:37 PM, Joel C. Ewing jcew...@acm.org said: I see no reason to require that there be a browser that would run under TSO to display the documentation on a 3270. The OP wrote In this case the user can access the mainframe only via TSO certificates. That narrows his options. I can't imagine running z/OS these days without TCP/IP connectivity, I've seen plenty of posts here from people who have to live with firewall rules that make their lives more difficult than necessary. Note that I am not defending such rules; I consider them to be a RPITA. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS WIKI access from a mianframe (TSO)
In CAJTOO5_Mi=+d+vixawrygrnzo3q9n_yexxepe0nacgpbyu9...@mail.gmail.com, on 03/03/2014 at 02:30 PM, Mike Schwab mike.a.sch...@gmail.com said: Lynx runs under Unix System Services (z/Unix). There is an OMVS shell for running Unix under TSO, but can you render wiki pages with a text browser? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
Wow, this ended up way more interesting than I thought it would! Thanks for the info Rob and John! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Tuesday, March 04, 2014 11:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection The difference is that TSO (and ISPF) runs in problem state and the jobstep is unauthorized. In batch, when executing a program linked AC(1) that comes from a valid APF authorized library, then the entire jobstep is considered authorized. TSO must jump through a few hoops to attempt to provide a safe way of invoking the authorized program - this involves having a parallel authorized jobstep TMP task and suspending all TCBs on the non-authorized leg while the authorized code is executing. Hence the various tables in TSO (and ISPF) to define these special circumstance commands (or programs) that can run authorized. Throw into the ring, the confusion that can occur with TSOLIB and ISPLLIB (and STEPLIB) - it can get messy to code applications and debug problems in this area - especially when your code is running on other people's systems. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: 04 March 2014 15:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection True, I have never understood that either, gil. It might more to do with executing the program in the appropriate TCB than a security exposure. Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, March 04, 2014 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection On Tue, 4 Mar 2014 08:54:43 -0500, Shmuel Metz (Seymour J.) wrote: In 9819019940159674.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 06:14 PM, Paul Gilmartin paulgboul...@aim.com said: I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. Because it would be a major security breach. That doesn't tell me much. Why? How? Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM Premiers New Master the Mainframe World Championship
http://ca.finance.yahoo.com/news/ibm-premiers-master-mainframe- world-131500257.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OCOPY fails to convert text
On 3 March 2014 20:54, Farley, Peter x23353 peter.far...@broadridge.com wrote: GIYF. I refer you to these Wikipedia references, the first of which makes it quite clear that iso-8859-1 is definitely NOT Windows, though it does call it ASCII-based; and the second of which is a nice reference for IBM-1047, from which you can see that there is a reasonable chance to convert between the two encodings, though not completely transparently, whatever IBM chooses to call the iso-8859-1 encoding. More than a reasonable chance; since IBM-1047 and ISO-8859-1 encode *exactly* the same set of displayable and control characters (what IBM calls Character Set (CS) 697, and ISO calls (duh) Latin 1)), converting without loss is trivial. Windows, when it uses them at all, uses code pages that contain displayable characters in places where 1047 et al have control characters, so it is not in general possible to convert from e.g. Western Windows 1252 to IBM-1047 without loss. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OCOPY fails to convert text
On Tue, 4 Mar 2014 12:24:41 -0500, Tony Harminc wrote: On 3 March 2014 20:54, Farley, Peter x23353 wrote: GIYF. I refer you to these Wikipedia references, the first of which makes it quite clear that iso-8859-1 is definitely NOT Windows, though it does call it ASCII-based; and the second of which is a nice reference for IBM-1047, from which you can see that there is a reasonable chance to convert between the two encodings, though not completely transparently, whatever IBM chooses to call the iso-8859-1 encoding. More than a reasonable chance; since IBM-1047 and ISO-8859-1 encode *exactly* the same set of displayable and control characters (what IBM calls Character Set (CS) 697, and ISO calls (duh) Latin 1)), converting without loss is trivial. Windows, when it uses them at all, uses code pages that contain displayable characters in places where 1047 et al have control characters, so it is not in general possible to convert from e.g. Western Windows 1252 to IBM-1047 without loss. Actually, it depends on your definition of loss. If both pages contain 256 code points, it may be posible to convert from one to the other, then back, and have the same thing you started with. The interim may not look the same, but that may not matter. I think I'll go with ASCII-based until Shmuel objects. And long thereafter. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Disabled wait
UA69565 http://www.ibm.com/Search/?q=UA69565co=uslo=anysn=lang=encc=USen=utfhpp= ftp://ftp.software.ibm.com/eserver/zseries/holddata/quarter.txt ++HOLD(HDZ1D10) FMID(HDZ1D10) REASON(AA42179) ERROR DATE(13365 ) COMMENT(SMRTDATA(FIX(UA69565) SYMP(PRF) CHGDT(131231))) UA71730 http://www.ibm.com/Search/?q=UA71730co=uslo=anysn=lang=encc=USen=utfhpp= ftp://ftp.software.ibm.com/s390/holddata/year.txt ++HOLD(HBB7780) FMID(HBB7780) REASON(AA43690) ERROR DATE(13352) COMMENT(SMRTDATA(FIX(UA71730) SYMP(FUL) CHGDT(131218))) On Tue, Mar 4, 2014 at 8:25 AM, Staller, Allan allan.stal...@kbmg.com wrote: UA69565 closes APAR OA42179 UA71730 closes APAR OA43690 As of a few minutes ago, neither PTF was indicated as a PE. I checked the cover letters for the z/OS 2.1 versions of those PTF's (UA69566 and UA71731) and of the 2 I would consider UA71730 the most likely culprit. I would check you apply run for failures during the application of these PTF's, or bypass of a pre -req. Can you post the SMPOUT from your apply run? I can't think of anything else that would cause this. snip But through some slow application of maintenance I determined the 2 that PTFs that cause the DW are UA69565 and UA71730. I've no idea why they cause an issue, but when I apply them I get the DW. To make it even more odd is those PTFs are applied to other z/OS 1.13 systems I run. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IMS DB Segment modification
If the field is to drop is not defined to IMS, IS is not aware of the change at all. If the field is defined to IMS, you should check why. It might be a key or search field and shouldn't be deleted unless you change the database definition, unload and reload the data. You should consult your DBA and ask him to look into the DBD in question. ITschak On Tue, Mar 4, 2014 at 3:32 PM, Ron Thomas ron5...@gmail.com wrote: Hello. We IMS DB in this we are planning to drop one of the fields from one segment which is having 2 bytes and expand the adjacant field from the current 2 bytes to 4 bytes. We are modifying the programs for this, so kindly let someone let me know what things we need to take care for the modified version of DB to be implemented in production? Thanks Ron T -- 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
zFS aggregate growth amount query
As Allan mentions there is a APAR on this subject. It is marked RESTART/BOOT/IPL/FUNCTIONLOSS. We have not experienced the problem, but the Issue #2 listed in it sounds pretty bad if you are in a Shared Filesystem sysplex environment. If only one system in your plex has the bad PTF installed, it could show itself during an IPL of a different system in the plex without the PTF installed. Allan Staller said: Other recipients: There is a currently open APR on ZFS secondary allocation. See OA44214. I have always had success w/ zfsadm agggrow -size (final desired size). Check the fine manual for syntax. I am sure the above is incorrect. snip There is a currently open APR on ZFS secondary allocation. See OA44214. I have always had success w/ zfsadm agggrow -size (final desired size). Check the fine manual for syntax. I am sure the above is incorrect. snip Listcat the zFS. It is the secondary allocation by default, I do believe. You can override this by hand with the zfsadm grow command but if it is done as a result of the AGGRGROW parm on the mount it is the secondary allocation of the linear VSAM cluster, IIRC. /snip snip I've developed a zFS aggregate am loading it up with a fairly large amount of data. I keep on seeing console messages sequences like: IOEZ00078E zFS aggregate cluster name exceeds 99% full (1282681/1285920) (WARNING) IOEZ00312I Dynamic growth of aggregate cluster name in progress, (by user ). IOEZ00309I Aggregate cluster name successfully dynamically grown (by user ). IOEZ00078E zFS aggregate cluster name exceeds 99% full (1285920/1289160) (WARNING) My question is with regard to the amount that the aggregate has grown by. The difference between the '1285920' and '1289160' is 3240 - presumably that is # 8k-byte blocks, but available documentation appears to be woefully inadequate. Who defines that '3420'? I certainly didn't specify it when creating the cluster, nor with any parm value when formatting it with IOEAGFMT. When I look at either IOEFSPRM or IOEPRMxx, all I see is a bunch of comment lines. /snip - show quoted text - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to list...@listserv.ua.edujavascript: with the message: INFO IBM-MAIN Show trimmed content _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Writing a Mainframe Systems Programmer Resume
I would like to invite anyone attending next week's SHARE conference in Anaheim to come to my session on How to Write a Resume for a Mainframe Systems Programmer (session 15391, Tuesday, March 11, 12:15pm). It is the 8th time I have given this presentation at SHARE and it contains a lot of useful information and samples for the aspiring resume writer. Here is a link to my session: http://share.confex.com/share/122/webprogram/Session15391.html If you cannot attend, feel free to send me an email (or LinkedIn message) and I will send you a link to my PowerPoint slides (which will be available after March 11). If you're at SCIDS Sunday night, definitely track me (and Chris Evans) down and say hi. I am reachable by cell phone all week. Joe Gallaher j...@spci.net 323-822-1569 work 323-363-7259 cell http://www.SPCI.net http://www.linkedin.com/in/joegallaher You wouldn't hire a COBOL programmer to install your operating system. Why use an applications recruiter for your systems management needs? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
On Tue, 4 Mar 2014 09:25:10 -0600, Paul Gilmartin paulgboul...@aim.com wrote: . . . Because it would be a major security breach. That doesn't tell me much. Why? How? Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? Perhaps you could get away without AUTHPGM, but AUTHTSF is required. Actually when the TSO Service Facility was created, the designers did not see a need for this, and they made use of AUTHPGM, which together with AUTHCMD already existed at that time. Some time later they saw the error of their ways and an APAR added AUTHTSF. For a long time the only place where the reason for this was explained was in the APAR that introduced it, and at some point even that was hidden from customers' view. These days the reason is explained in the TSO/E documentation: ... programs in this list (AUTHTSF) should not accept parameters that are pointers to code what is to be executed (such as exit routines) as this might introduce an integrity exposure. Such parameters cannot be provided when executing the program using JCL. The documentation even goes on to mention that IDCAMS should never be added to AUTHTSF. IDCAMS was the specific program that prompted the APAR that introduced AUTHTSF, but any number of other programs could have the same issue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
About pointers to executable code Andy Wood wrote: | Such parameters cannot be provided | when executing the program using JCL. While this is of course literally true, it is not usefully so. It is, for example, possible to to provide offsets (in the form of unsigned external decimal-digit strings) that a knowledgeable routine can convert into such pointers. It is indeed possible to provide 8- or 16-digit external hexadecimal-digit pointer representations (in a PARM= string) that are immediately convertible into virtual-storage addresses. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
John, I ran into issues with that doing Rexx from a Cobol STC, that we haven't converted to C yet. I ended up calling a IRXJCL rexx stub that did a LINKMVS to some code..I cheated , I plead guilty ….lol Regards, Scott From: John McKown Sent: Tuesday, March 4, 2014 11:05 AM To: IBM Mainframe Discussion List It has to do with the fact that the APF code itself could become corrupted (if loaded into key-8 storage) by some user code running under a different TCB. Or that some key 8 storage area used by the APF code could be corrupted by user code running on a different TCB. This corruption could be either due to poor coding, or even a malicious attempt to get non-APF code running in APF mode. TSO has an interface, IKJEFTSR, which can run APF safely under TSO. But it does this my using a separate TCB structure to run the APF code and doing a STATUS STOP on all the other TCBs in the address space. Well, most of them, anyway. However, things running via IKJEFTSR cannot do ISPF functions for the very same reason. The ISPF code runs on a different TCB and that TCB is in a more or less hard wait. ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4b780/23.1 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4b780/23.1.2 On Tue, Mar 4, 2014 at 9:51 AM, Leonardo Vaz leonardo@cn.ca wrote: True, I have never understood that either, gil. It might more to do with executing the program in the appropriate TCB than a security exposure. Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, March 04, 2014 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection On Tue, 4 Mar 2014 08:54:43 -0500, Shmuel Metz (Seymour J.) wrote: In 9819019940159674.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 06:14 PM, Paul Gilmartin paulgboul...@aim.com said: I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. Because it would be a major security breach. That doesn't tell me much. Why? How? Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? -- 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 -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- 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: ISPF storage protection
In 769b2e18f7b2fa48b3adea85570a28769a560...@mtl-hq-x01.cn.ca, on 03/04/2014 at 03:51 PM, Leonardo Vaz leonardo@cn.ca said: Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? Yes. What makes it a security breach is allowing an unauthorized program to invoke it authorized in an uncontrolled manner. IBM has written voluminously about this issue. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OCOPY fails to convert text
In 2783130373802539.wa.paulgboulderaim@listserv.ua.edu, on 03/04/2014 at 12:21 PM, Paul Gilmartin paulgboul...@aim.com said: I think I'll go with ASCII-based until Shmuel objects. And long thereafter. That would be impossible. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
