Re: Bob Shannon
Thanks for sharing this sad news. My condolences to his wife, family, and friends. RIP Bob Klaus Stanislawiak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "old" OS/390 documentation
Dave, you may want to try the "IBM Publications Center": https://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss It helps if you know the publication number, but there is also a search function available. HTH Klaus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using COBOL on ZIIP via SRB etc
You may want to review what happened to zPrime. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retrieve Job JCL
David, You could use the Spool Data Set Browse function to read the JESJCLIN data set for the job. Please have a look at: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.hasc300/daldsnam.htm Regards, Klaus Stanislawiak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Parmlib Support - OA52650
7B0 (last three characters of the FMID) corresponds to z/OS 2.3. Regards, Klaus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: bama.ua.edu not reachable?
Hi Kees, I had the same symptom since last week. Try to use "listserv.ua.edu" instead. HTH Regards, Klaus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LAST ALTER date in GDG base.
According to this announcement by the late Mark Thomen: https://listserv.ua.edu/cgi-bin/wa?A2=ind0201=ibm-main-archives=0=D===425524 the corresponding field GDGALTDT has been added to the Catalog Search Interface for z/OS 1.3 . The catalog field has probably existed before. Klaus Stanislawiak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Internals of Catalog
You may also want to look at Chapter 6 of the Redbook "ABCs of z/OS System Programming Volume 3": http://www.redbooks.ibm.com/abstracts/sg246983.html?Open HTH Klaus Stanislawiak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE V2 MaxGen Limit Query
Please have a look at APAR OA43951 and the corresponding solution: > Add a new field to the DFA DFAMAXGN which contains the > maximum number of generations this system supports. With this information it should be possible to access the field in the DFA from REXX. HTH. Klaus Stanislawiak -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dyck, Lionel B. (TRA) Sent: Tuesday, July 26, 2016 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PDSE V2 MaxGen Limit Query Is there a way to query the current MAXGENS_LIMIT from the SMS configuration in either REXX or ISPF? I'm looking for a way to prevent a user from specifying a larger maxgen than is allowed in a dialog I'm working on. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EAV bug or feature?
On 5/10/2016 10:30 AM, Tom Conley wrote: > I ran many different searches trying to find this information, also > using the term "cylinder-managed" space. While it directed me to the > EAV section of the DFSMS Using Datasets manual, not one example of how > to allocate a dataset in the cylinder-managed space. Tom, You may also want to take a look at some Redbooks. These two provide a comprehensive introduction to EAVs, even with examples: DFSMS V1.10 and EAV Technical Guide, SG24-7617-00 (Chapter 18) z/OS Version 1 Release 11 Implementation, SG24-7729-00 (Chapter 4) And those two provide information about more recent enhancements: z/OS Version 1 Release 13 Implementation, SG24-7946-00 (Chapter 24) z/OS V1.13 DFSMS Technical Update, SG24-7961-00 (Chapter 10) Regards, Klaus Stanislawiak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES3 to JES2 Migration (was JES2 to JES3 Migration)
JES2 supports 8-character job class names as of z/OS 2.1, also explained in the Redbook I mentioned earlier today. I suggest to review that Redbook first, and then the latest SHARE Orlando presentations by Tom Wasik "What's new in z/OS 2.2 JES2". Conversion should be easier today than a few years ago. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES3 to JES2 Migration (was JES2 to JES3 Migration)
Cheryl. You may want to take a look at the IBM® Redbook® "JES3 to JES2 Migration Considerations": http://publib-b.boulder.ibm.com/abstracts/sg248083.html?Open And new functions (Job Execution Controls) have been introduced with z/OS 2.2 JES2. They are not yet mentioned in the Redbook, but may provide additional help with the migration. Klaus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inquire intrdr default job class
I suggest to take a look at JES device information services (SSI function code 83), described here: https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaf200/ssifc83.htm The corresponding macro IAZSSJD indicates that the SSI returns a "Reader common section" containing field JDRCDFJC (Default job class). HTH Regards, Klaus Stanislawiak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DESERV macro error from IBM affecting PDS 8.6 HISTORY function against PDSE load modules
Sam,
Thanks for your hint. However, I would expect the final fix to this error to
look different,
because a subpool number is not meaningful in the context of DESERV FUNC=GET_G .
(please see:
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad500/deservgetg.htm
)
So this AIF statement should probably just be restored to the HDZ1D10 level and
again just read:
AIF ('FUNC' EQ 'GET').CHKSUB00398300
Anyway, I still have a PMR open regarding DESERV (see APAR OA45505) and I can
try to report this issue in that context if you like.
Regards,
Klaus Stanislawiak
On Thu, 26 Feb 2015 21:58:23 -0500, Sam Golob sbgo...@cbttape.org wrote:
Hi Folks,
There was an error in the PDS 8.6 program which wasn't an error in PDS.
It showed up when you wanted to do a HISTORY subcommand against a
load module in a PDSE. Instead of the display, you got a S378 abend.
The real error was caused by an error in IBM's DESERV macro in SYS1.MACLIB.
John Kalinich created a corrected version of the DESERV macro, which,
when concatenated ahead of the one in SYS1.MACLIB, fixed the problem.
The error in DESERV was detected by Greg Price, in summary:
DESERV does not set DESP_SUBPOOL_FLG, which causes default subpool 0 to be
used. Subsequently the FREEMAIN fails with ABEND S378-14 because storage
is not allocated in subpool 21. The cause is a logic error in
SYS1.MACLIB(DESERV) at the z/OS 2.1 level -
The fix (from Greg Price): change to the DESERV macro
The AIF instruction that checks *(('FUNC' EQ 'GET') **AND** ('FUNC' EQ
'GET_G'))* should be *(('FUNC' EQ 'GET') **OR** ('FUNC' EQ 'GET_G'))*.
The second condition (GET_G) was added in z/OS 2.1 (FMID HDZ2210, RMID
UA71462 on SYS9).
Code change in DESERV (our own copy of it):
DAIF (('FUNC' EQ 'GET') AND X00398320 DEL= 1 02251 02251
I .* Change AND logic to OR on AIF below DRK FEB15 00398200 INS= 3 02251 02251
I .*00398200 02252
IAIF (('FUNC' EQ 'GET') OR X00398320 02253
For the CBT Tape, we had to create new load modules for PDS 8.6, which were
assembled against the revised version of the DESERV macro, concatenated
ahead of SYS1.MACLIB. I have just re-posted on the Updates page of
www.cbttape.org the following files:
File 035, File 135 (load modules), and File 182, member Z035XMIT changed.
I tested the revised version of the PDS 8.6 program and it correctly
displayed a HISTORY of a load module in a PDSE.
We hope that this clears up this problem with PDS. Now we have to enter
a PMR with IBM. (Who's gonna do it?)
All the best of everything to all of you.
Sincerely, Sam
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MTRACE?
John, You may also want to slay the references to selectable units in z/OS MVS System Messages, Vol 7 (IEB-IEE), please see the Explanation and Operator response sections for message IEE026I func NOT SUPPORTED, e.g.: func may also be a command dependent upon a selectable unit. If it is such a command, the selectable unit supporting the command has not been installed on the system. If you prefer I can also send an RCF ...? Klaus Stanislawiak On Thu, 12 Feb 2015 08:53:19 -0500, John Eells ee...@us.ibm.com wrote: I think it's safe to say that MTRACE is older than many members of this list...who I'm sure won't recall the SU bit string or SUs. I recall that MTRACE was there by MVS 3.8 SE2, but I can't vouch for it being present further back than that. -- John Eells (as it happens, the slayer of the IHASUBIT macro) z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problem defining LU Range
Back then the LU names had to consist of the LU base name and the range specification (i.e. at the end). So a definition like BIHA1001..BIHA1256 should work. Regards and good luck, Klaus Stanislawiak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What are STC, JOB and TSU?
Hi Lindy, This is what I find on the related SDSF help panel (ISFJDF2): TypeType of address space: job, started task, TSO user, or initiator And there are address spaces that run under the master subsystem and do not have a JES job id. And in JES3 you cannot derive the ... type from the job id as it will always begin with a 'J'. HTH (a little) Klaus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES3 job ids
On all the JES3 systems that I have seen (since OS/390 V2R5) all jobids have always looked like JOBx for jobs, STCs and TSUs. The entries S0xx and J0xx in the presentation may originate from STCs and TSUs that were running under a secondary JES2 on the same system. But Ed Jaffe will probably let us know if he has a different explanation. Regards, Klaus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES3 job ids
This is what I found in the Glossary of a back level documentation (z/OS V1R4.0 JES3 Introduction, SA22-7551-02): job ID. An 8-character identifier used by JES3 to uniquely identify any job in a JES3 complex at any moment in time. The job identifier is of the form JOBn where n is the job number with the appropriate number of leading zeroes, if the job number is 99,999 or less. Otherwise, the job identifier is of the form Jnnn, where nnn is the job number with the appropriate number of leading zeroes. BTW, there is also a JES3-L list server where more JES3 customers are registered. Unfortunately I am currently not able to log on there for whatever reason ... Regards, Klaus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES3 job ids
Now back with access to JES3-L, I found an old entry by Ed Jaffe that might explain why you have seen S0xx and J0xx job IDs in that presentation. I hope Ed does not mind if I quote him from there: On Thu, 12 Sep 2002 16:46:06 -0700 Edward E. Jaffe said: In JES3, you can't rely on the job ID to tell you the job type. All job IDs always appear as JOBx (or Jxxx in z/OS V1R2), whether a job, started task, or TSO user. (E)JES provides a feature to merge the job type and job ID into a single displayable job ID column. Regards, Klaus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extended Format V2 PDSE V2
You may want to take a look at this Redbook z/OS V2.1 DFSMS Technical Update: http://www.redbooks.ibm.com/Redbooks.nsf/RedpieceAbstracts/sg248190.html?Open and at that Share presentation The Future of PDSE: The Version 2 Format: https://share.confex.com/share/122/webprogram/Session15083.html Regards Klaus Stanislawiak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DCBs and DCBEs - Could IBM have done it any worse?
On Tue, 14 Jun 2011 12:41:11 -0500, Paul Gilmartin wrote: I prefer to be told when I make a programming error. It looks that they are going to tell us soon. Please see APARs OA42701, OA43000 and OA43037. -- Klaus Stanislawiak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
