AW: Re: EAV bug or feature?
>So if you want to use EAV's, make them SMS. ... ... and be prepared to have to deal with strange errors with software which is not EAV-savvy, i.e. which show strange behaviour with cylinder managed block addresses. E.g. code written with SAS-C may not like them. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Suggestion for conditioning step on symbols
>So, changed those to non-printable. That would fix it up, but the code is >still suffering from having to change >horses in mid-stream. And there's the >fat-fingering, which is an all-too-common issue. > >Leads to sort symbols, WHEN=INIT, two FINDREPs with STARTPOS and DO=1 and >SHIFT=NO. > >//CHEKPARM EXEC PGM=SORT,PARM='JP1"&PARM1",JP2"&PARM2"' >//SYMNAMES DD * >* RECORD FIELDS TO CREATE AND MANIPLUATE >FIRST-COMPARATOR,*,80,CH >SECOND-COMPARATOR,*,=,= >* CONSTANTS >DUMMY-VALUE1-TO-REPLACE,X'FD' >DUMMY-VALUE2-TO-REPLACE,X'FE' >//SYMNOUT DD SYSOUT=* >//SYSOUT DD SYSOUT=* >//SORTOUT DD SYSOUT=* >//SYSINDD * >OPTION COPY,STOPAFT=1 > >INREC IFTHEN=(WHEN=INIT, >OVERLAY=(FIRST-COMPARATOR: >DUMMY-VALUE1-TO-REPLACE, >79X, >SECOND-COMPARATOR: >DUMMY-VALUE2-TO-REPLACE, >79X)), >IFTHEN=(WHEN=INIT, >FINDREP=(IN=DUMMY-VALUE1-TO-REPLACE, >OUT=JP1, >STARTPOS=1, >DO=1, >SHIFT=NO)), >IFTHEN=(WHEN=INIT, >FINDREP=(IN=DUMMY-VALUE2-TO-REPLACE, >OUT=JP2, >STARTPOS=81, >DO=1, >SHIFT=NO)) >OUTFIL INCLUDE=(FIRST-COMPARATOR, >EQ, >SECOND-COMPARATOR), >NULLOFL=RC4 >//SORTIN DD * >CONTENT IMMATERIAL > >If concerned that it is overly wordy (some people have a problem with that), >... Not sure whether I shall laugh or cry. DFSort is a great tool, no doubt; it's control statements (I intentionally don't called it "language") are a nightmare, no doubt. Hopefully noone will ever consider the above as something suitable for production. Overkill; not maintainable. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: ADRDSSU message Keywords Clarification
>There are manuals for DFSMSdss that should be helpful on the ibm website. ADR and ADRY messages are documented "z/OS MVS System Messages Volume 1 (ABA - AOM). As obvious as can be, isn't it? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ADRDSSU PRINT function not listing KEY (of CKD) as separate item?
Long time since I last have had a look at this. I'm printing the tracks of a PDS (not PDSE) using ADRDSSU's PRINT function. PDS directories are one very few users of hardware key (K in CKD). I had expected DFdss to list the key data separate from the actual data (the D in CKD). It seems the print format concatenates the key and data parts in the listing seamlessly. I could not find this described in the manual. So, just to be sure my memory is correct: On the hardware, the C, K and D fields are separate blocks of data separated by GAPs, right? It is only DFdss that combines the when printing. -- Peter Hunkeler -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: ADRDSSU PRINT function not listing KEY (of CKD) as separate item?
>Yes and no. On true physical CKD devices that would be true. On today's emulated devices it isn't. Yes, of course. I'm aware of the fact that today the CKD architecture is only emulated on FBA devices by the storage subsystems. >I believe that DFDSS PRINT uses a Read-count-key-data command CCW to read data. The count, key, and data would be then be combined and returned by the control unit as a single block of data which is subsequently formatted by DFDSS. Yet still the count field is printed on a line by its own. This is why I had expected the key field to printed separately from the data field as well. But I'm fine with this. Just wanted to make sure I'm not misinterpreting anything. Thanks Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: CREATED date for migrated data sets?
> Alas, ISPF DSLIST does not show created date for migrated data sets. Those dates are in the data set's DSCB. There is none for migrated ones. So for once, ISPF is not guilty. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Questions on DPMOD
> It's been over 20 years since I had to deal with problems in this area > (MVS/ESA SP5.1), ... And UNIX Systems Services did not exist at the time. It was MVS/ESA SP5.1 that actually gave birth to z/OS UNIX, which was called OpenEdition initially, ISTR. It was optional to start or not to start the UNIX kernel (OMVS) at that time. But the component was part of MVS/ESA. (With MVS/ESA SP4.3 OE was an optional add on, I think) Back to the OP's topic. I read in "z/OS V2R2 Programming: Assembler Services Guide", chapter "Chapter 3. Subtask creation and control", topic "Task Priority": "The dispatching priorities of the tasks in an address space do not affect the order in which the control program selects jobs for execution because that order is selected on the basis of address space dispatching priority. Once the control program selects an address space for dispatching, it selects from within the address space the highest priority task awaiting execution. Thus, task priorities may affect processing within an address space." This makes my wonder. My understanding, which maybe is not entirely correct, is that the dispatcher only looks at the work unit queue (WUQ) for the type of processor, when a processor needs new work. It picks the first work element block (WEB) form the queue and dispatches it. No need to perform an search in the ASCB anymore. That was the goal of the dispatcher redesign (MVS/ESA 5.1?): Improve dispatching performance by eliminating lengthy searches. Each TCB or SRB is represented by a WEB, which is placed on the WUQ when the TCB or SRB becomes ready (dispatchable). It is at this time where the ordering according to the dispatching priority takes place: o A Global SRB at the top of the WUQ (behind other Global SRBs already on the queue). o A Local SRB gets its place in the queue according to the AS's current dispatching priority and is placed ahead of any Preemptible SRB or TCB from that AS which may already be on the queue. o A Preemptible SRB or TCB gets its place in the queue according to the AS's current dispatching priority and is placed behind any WEB of any AS with equal dispatching which may already be on the queue. If this is all correct, the "Task Priority" must be considered when the WEB is placed on the WUQ. The system must look at all TCB WEBs whic may be on the WUQ for *that address space*, and insert the new TCB according to the "Task Priority". Remember that WLM may change the dispatching priority of a Service Class once every 10 seconds trying to help a Service Class missing its goal. All WEBs which have that Service Class assigned will get the new dispatching priority at time. And this may change the order of WEBs already on the WUQ. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: TSO receive on MultiVolume PS error
> However, I don't think that is your problem. The XMIT dataset should be FB 80 3120. Just for the records: The XMIT data set *must* be RECFM=FB, LRECL=80. The blocksize should be as large as possible to minimize the number of I/O operations to be run. 27920 is optimal. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: TSO receive on MultiVolume PS error
Lizette, I agree that the doc needs to be updated. I'll submit an RCF. Gil's post made me thinking. As a matter of fact, I've been using larger blocksizes for XMIT data sets for a long time, but only when allocating them for FTP to upload one. So, RECEIVE happily accepts larger block sizes. I never cared to look at what TRANSMIT allocated. I just tried and found that TRANSMIT overrides the block size with 3120, when the data set already existed (and uses this when it allocates the data set). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Questions on DPMOD
Thanks, Greg, for the pointer to the presentation. I did not read anything which would contradict my understanding. I conclude below text, which I cited previously, needs some rework. I' ll submit an RCF. > Back to the OP's topic. I read in "z/OS V2R2 Programming: Assembler Services > Guide", chapter "Chapter 3. Subtask creation and control", topic "Task > Priority": > "The dispatching priorities of the tasks in an address space do not affect > the order in which the control program selects jobs for execution because > that order is selected on the basis of address space dispatching priority. > Once the control program selects an address space for dispatching, it selects > from within the address space the highest priority task awaiting execution. > Thus, task priorities may affect processing within an address space." -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Displaying Users and Processes for UNIX z/OS Functions
>I'd try the UNIX command, "ls -alrt /tmp", which would show timestamps, >user IDs, and file sizes. It's at least a good start. Automate with BPXBATCH >or BPXWUNIX. That would not show files that have been unlinked but are still in use (open). I understand it is quite common for temporary files: OPEN (create mode), UNLINK, WRITE & READ to and from file, CLOSE. The temporary file will be deleted a CLOSE time. In the case of unnormal end, the kernel will CLOSE the file, thus the file will be deleted also in that case. No zombie file left behind. "ls" will not show this file. "fsinuse" will show processes that use files in a specific directoy, but /tmp might be used by many. So, how do you indentify the one eating up all space? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Where is format of Job ID documented?
> >Hmmm. If a batch job spawns (not forks) a subprocess with _BPX_SHAREAS=YES wouldn't that subprocess run under the parent's JobID; no BPXAS, no STC? Local child processes, started via local spawn(), or attach_exec(), or attach_execmvs(), are run in the same address space as the parent process. I.e. in the TSO, batch job initiator, APPC initiator or STC address space. (Don't know much about APPC programs, but I assume there is nothing prohibiting then to use UNIX services.) The same applies to the case when an non-UNIX program is being dubbed because it is using A UNIX service now, i.e. when it becomes a UNIX process. Jobname and jobid are address space level attributes, not task or process level. Non-local child processes, started via fork(), or non-local spawn(), *always* run in UNIX initiator address space, aka BPXAS. BPXAS was introduced with OS/390 V1.3 (I seem to remember). Before that, APPC initiators were used to provide a home for non-local child processes. -- Peter Hunkeler -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Where is format of Job ID documented?
>>I guess IBM's thinking is that we should just treat it as a magic cookie. It >>is guaranteed to be 8 EBCDIC characters that will identify a job or the like. >>End of story. >> >Used to be 7, IIRC. Don't you mix that up with TSO Userids which are restricted to 7 charactrers? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Where is format of Job ID documented?
>Isn't the APPC initiator structure a complete clone of JES2? In other words, >it has its own rules and JES2 has no relation whatsoever with APPC jobs or its >jobids? As stated in another post I'm not too familir with APPC, but is there anything prohibiting an APPC program from dynamically allocating a SYSOUT file? If not, JESx must know about that address space and thus the Annn number would be managed by JESx the same way JESx is managing the number for TSU, STC, and batch jobs. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Where is format of Job ID documented?
>... OTOH: It might run under Master Scheduler not JES. Makes perfect sense to me. Firstly MOUNT is an MVS command, and secondly, one would not be (or have been) able to MOUNT a volume when JESx was down. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Highest address "below the bar"
>> Is the highest 31-bit address 7FFF or 7FFF? >> I ask because the largest region size you can request is 2096128K or >> 2047M, and 2096128 * 1024 = 2,146,435,072 (x7FF0). > >For diagnostic purposes, then 4K page at 7000 is always >left invalid in z/OS. That makes the highest numbered, accessible byte to be at address x'7FFFEFFF' -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Where is format of Job ID documented?
>The real question behind the question was "if I am processing JOB ID's what >should I expect to see, and if I am presenting them to people who have never >heard of JES, what should they expect to see and what does it mean?" What does it mean to people that have not heard of JES? I guess such people the have not much knowledge about z/OS either. In that case, I'd say don't tell them anything about the jobid at all. Why? Because it is not telling you much anyway. If I run a shell command from TSO, it will normally be run in my TSO address space, tos the jobid associated with this command would be Tnnn. If I run the command in batch, it might be running in the batch job's AS or in a UNIX initiator AS (BPXAS), so the jobid would be Jnnn or Snnn, resp.. And if the same command is run from an STC, it mit be running in the STC's AS or again in a UNIX initiator AS, but the jobid will be Snnn in both cases. But even standard MVS services might be run as STC or as batch job. Some run CICS or IMS as STC, some as batch job. So, CICS/IMS will show up as either Snnn or Jnnn. -- Peter Hunkeler -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: WAIT >1 (Friday type question, a day late)
>I just had occasion to RTFM on WAIT. I'm sure WAIT with an event count >greater than one seemed like a terrific idea at the time, but has anyone >ever used it? What's an application for "wait for any two of these five >events to occur"? I once wrote a utility that waits for either an MVS STOP command or until a specified time interval has expired. It sets up the timer and the CIB, then WAITs for one of the two events to happen. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Display in ULOG of SDSF
>I have captured the CONSNAME, CONSID and CART when the modify is done and I >use the CONSNAME >and CART to issue the WTO. >I have not coded MCSFLAG,ROUTCDE or DESC. I 've coded CONSID=CIBXCNID,CART=CIBXCART and DESC=(5,7) on my WTOs. Works fine. I'm not sure DESC=5 is really needed, as I just tried with DESC=7 and still got the response in SDSF ULOG. DESC=5 is marking the WTO as "immediate command response". MPF will not suppress messages with DESC=5. Not sure if this is the only purpose of DESC=5. Do you happen to have SDSF running in two ISPF sessions? Did you go into ULOG on both? If so, messages will only show up on the session where you entered ULOG first. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TIOT exceeded
>You could also try something a little more sophisticated - like dynamically >allocating the data sets (take a look at IDCAMS, which can access the data >sets via dynamic allocation and avoid the batch limits.) Isn't it true that for non-authorized programs dynamically allocating a data set still adds an entry to the TIOT? Only authorized code is allowed to as for the entry to be added to the XTIOT. I guess IDCAMS is using the XTIOT, but user programs, including TSO and ISPF do not. OTOH, why not deleting the GDSs with IDCAMS "DELETE your.gdg.base.* MASK" -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: From when I didn't have gray hair nor needed glasses
>http://petelancashire.com/gallery/main.php?g2_itemId=7139 I guess you can't make this availble to bitsavers, can you? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TIOT exceeded
>Is the JCL limit fundamental or merely to preserve compatibility with legacy
code. If the latter, a DD parameter, XTIOT={Y|N} might be more useful
than a query or a warning.
Since the TIOT is at task level, the parameter would belong to the EXEC rather
than the DD statement, wouldn't it?
--
Peter Hunkeler
--
Peter Hunkeler
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: TIOT exceeded
> The DEL 'gdgbase' MASK could take out more datasets than you want. Good catch. Thanks. It seems I wasn't fully awake when I posted my suggestion. >Which is Why I put in an RFE for DELETE "gdgbase.GV##" MASK as an enhancement. I didn't look at your RFE, but I understand your requirement is exactly deleting all GDSs of a GDG without deleting the GDG itself. If so, wouldn't a new function "DELETE entryname GDS" be more clear and easier to use? The GDS option would require that "entryname" is a GDG, and it would delete all generation data sets (GDS) currently associated with the GDG. Questions would be how to handle newly created, but not yet rolled-in GDSs (jobs running in parallel). And what about new GDS created in step n of a job running in parallel, and step n+m referring to that GDS? There are probably more conflicts to think about -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: TIOT exceeded
>> >>Since the TIOT is at task level, the parameter would belong to the EXEC >>rather than the DD statement, wouldn't it? > >The real difficulty lies is in knowing that the running program, and anything >it calls, can tolerate the use of XTIOT entries vs TIOT entries. A step level switch, i.e. EXEC parameter, would make sense for exactly this reason, I guess. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OT: Test regarding ReplyTo - Please ignore
Havong some troubles with Reply-To. Please ignore this message. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: OT: Test regarding ReplyTo - Please ignore
Replying from AltaMail. -- Peter Hunkeler Von: Peter Hunkeler An: IBM-MAIN@LISTSERV.UA.EDU Betreff: OT: Test regarding ReplyTo - Please ignore Datum: 24.06.16, 12:28 Havong some troubles with Reply-To. Please ignore this message. -- Peter Hunkeler -- 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
Aw: AW: OT: Test regarding ReplyTo - Please ignore
Relaying from GMX Webmail -- Peter Hunkeler > Gesendet: Freitag, 24. Juni 2016 um 12:29 Uhr > Von: "Peter Hunkeler" > An: IBM-MAIN@LISTSERV.UA.EDU > Betreff: AW: OT: Test regarding ReplyTo - Please ignore > > Replying from AltaMail. > > > -- > Peter Hunkeler > > > Von: Peter Hunkeler An: > IBM-MAIN@LISTSERV.UA.EDU Betreff: OT: Test regarding ReplyTo - Please ignore > Datum: 24.06.16, 12:28 > > > Havong some troubles with Reply-To. Please ignore this message. > > -- > Peter Hunkeler > > -- > 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
AW: Re: [Bulk] Re: [IBM-MAIN] Minimum Volume Sizes in the Wild
When I was with IBM Education, we used to run class labs on minimal z/OS (OS/390, MVS/...) systems as VM guests. The volumes were VM mini volumes just as large as needed. If VM is still the base for those labs, I'm pretty sure there still are volumes of various small sizes. Not sure however if this matters for your query. --Peter Hunkeler -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: Tuesday, June 28, 2016 9:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Minimum Volume Sizes in the Wild What is the *smallest* volume size everyone sees in general use? For example, will we create any problems if we assume that "everyone" has or can define at least a 3390-9 size volume these days? What if we chose 3390-27? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Minimum Volume Sizes in the Wild
When I was with IBM Education, we used to run class labs on minimal z/OS (OS/390, MVS/...) systems as VM guests. The volumes were VM mini volumes just as large as needed. If VM is still the base for those labs, I'm pretty sure there still are volumes of various small sizes. Not sure however if this matters for your query. --Peter Hunkeler >What is the *smallest* volume size everyone sees in general use? > >For example, will we create any problems if we assume that "everyone" >has or can define at least a 3390-9 size volume these days? What if we >chose 3390-27? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: IBM Knowledge Centre
>The search in KC, which provides links to pages in manuals it's found, appears >to only provide the Data Areas manuals for 2.2. It seems to me that the Data Areas manuals are missing again in the z/OS V2.1 MVS bookshelf. Has happened before. The are there in the z/OS V2.2 bookshelf (yes, I'm talking about the new KC). I've been ignoring the old KC because I considered it unusable and extreemely slow. But the new KC is much better once you find out how it works, especially the new touchy-touchy-like menu button at the upper left. If feel at home, but must say I save the link to the z/OS V2.1 bookshelf part: http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0 Just don't try to use it with IE (up to IE11), use Firefox, Chrome or whatever, just not IE. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS V2.1 MVS Data Area manuals missing in the Knowledge Center
Would anyone of the IBMers watching the forum know whom to contact to tell them that the zOS/ V2.1 MVS Data Area manuals are missing in the new Knowledge Center? The feedback link on the page seems to be just general feedback about IBM. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Short description of system address spaces
While educating colloeagues new to z/OS, I promised to come up with a short decription of all the system address spaces are for. Before starting to write this down, does anyone happen to have such a list they are willing to share? Note that I'm not takling about a description of elements and features. There is a manual providing this list. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Short description of system address spaces
A bit too brief -- Peter Hunkeler Von: Mike Schwab An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: Short description of system address spaces Datum: 01.07.16, 15:41 JOBNAME *MASTER* ALLOCAS ANTAS000 ANTMAIN APPC ASCH ASCHINT AUTOTSO AUTOVIEW AUTOVSSI AXR BPXAS * BPXOINIT CADASTRT CAENF CANSO2 CAOMS CATALOG CEA CONSOLE CRONH9 CSSMTP DB2DBM1 DB2DDBM1 DB2DDIST DB2DHNON DB2DHTCB DB2DIST DB2DMSTR DB2HNON DB2HNON DB2HTCB DB2IPROC DB2LPROC DB2MSTR DB2RPROC DB2TDBM1 DB2TDIST DB2TMSTR DEVMAN DHSCICS DHSCICST DMHCICSC DMHCICST DRS DUMPSRV EPAMOBM EPAMOBV ESCM FINIMHT1 FINIMHT2 FINIMSH1 FINIMSH2 FINIMSH3 FINIMSH4 FINIMSH5 FINIMSH6 FTPDCMP1 FTPDMON1 FTPDSSL1 FTPUSERH FTPUSSLH GRS GTZ HGLINK HIS HSMAUD00 HSMRPT00 HWIBCPII HZSPROC ICSF IDCDBTDF IDCISS IDCMFACB IEFSCHAS IMSCONH IMSCONHT IMSDBRC IMSDBRCX IMSDLI IMSDLIX INETDMNH INIT* IOSAS IXGLOGR JESXCF JES2 JES2AUX JES2MON LLA MHDMOBM MHDMOBSW MHDMOBV NET NETVIEW NETVSSI NETVTSO NETVUNIX OAM OMROUTEH OMVS PAGENT PCAUTH PERCICID PERCICIP PERCICIT PERMOBM PERMOBT PERMOBV PERMOBWM PERMOBWV PORTMAP RACF RASP RESOLVER RMF RMFGAT RRS SDBH SDSF SDSFAUX SMF SMS SMSPDSE SMSPDSE1 SNMPD SNMPIOB SNMPQE SWSH SYSBII SYSB2 SYSHSMH SYSLOGDH TADZMON TADZWEB TCAS TMONH TMONHHUB TMONHLFS TNF TRACE TSDH TWSH USSTCPH VLF VMCF VPS VPSVSV WLM XCFAS XOSFH XOSFT ZFS On Fri, Jul 1, 2016 at 7:01 AM, Peter Hunkeler wrote: > While educating colloeagues new to z/OS, I promised to come up with a short > decription of all the system address spaces are for. Before starting to write > this down, does anyone happen to have such a list they are willing to share? > Note that I'm not takling about a description of elements and features. There > is a manual providing this list. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: z/OS V2.1 MVS Data Area manuals missing in the Knowledge Center
> I heard back from the person I contacted. As I surmised, most of the people are off today (and, of course, Monday). However, perhaps this will tide you over for now: Thank you, John. Much appreciated. There is no hurry, at least not with me. I've got all of the PDFs on all machines I work on anyway. Too impatient to wait for the internet. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Short description of system address spaces
>I see that Mike responded with a long list of names, which includes (I >believe) a mixture of system address spaces and started tasks. That led me to >wonder whether you were using "system address spaces" as a technical term >(meaning things like *MASTER* and SMF and DUMPSRV but not things like RMF, >SDSF, RACF, etc.) or whether you really meant it as a generic term that would >encompass normal started tasks, The former, Walt. And to make it clear, I do not need a mere list of names; I know then. I looking for a short description of those. The z/OS Basics redbook that Mike pointed to is indeed a known good starting point. But it does not have a list of these adrdress spaces. Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Symlinks with $SYSNAME variable
>When I run ln -s command but it is not taking $SYSNAME but it is taking SYSTEM/etc The $ is a meta character to the shell; it asks the shell to replace the variable following the $ with the valur of the variable. If you want to keep the $ as $, you need to escape it by preceeding it with he backslash. ls -s /\$SYSNAME/etc /MaintP21/etc -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Symlinks with $SYSNAME variable
>And for the sake of additional, but unasked for documentation. If you want to >use any system symbol you happen to have defined you would use the following >syntax: >ln -s '$SYSSYMA/&yoursymbol./xxx'xxx >&SYSSYMA is a special keyword for a symbolic absolute pathname >&SYSSYMR is a special keyword for a symbolic relative pathname $SYSSYMA and $SYSSYMR ($ instead of &) would be correct. And to again complete the documentation: $SYSNAME is a special value that is recognized when found at the start of a symbolic link, and it resolves to the currents system *provided that* z/OS UNIX is configured with SYSPLEX(YES) in BPXPRMxx. With SYSPLEX(NO) it is resolved to "SYSTEM". In my reply, I didn't think of the possibility that the system was running with SYSPLEX(NO). $SYSNAME is not the same as &SYSNAME. The latter is a system symbols and would need either $SYSSYMA or $SYSSYMR to indicate that the next directory level in the path specified is a system symbol. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: [EXTERNAL] Re: IBM Knowledge Centre
I've been disliking the *old* KC so much that I almost always discarded any search result that pointed to the KC. I must admit that I do quite like the new KC. It is much faster than the old KC; I'd say very well usable. It provides good navigation posibilities *once* you get uses to open the tree view by clicking in the upper left corner. Search has given me good results do far. It's using a useful font size. I like the fact that (sometimes) you can switch between z/OS Versions while staying at the current topic: Sometimes there is a little drop down besides the topic which alliow this switch. What I absoultely dislike is the fact that it does not seem to work well with IE, probably when accessed from behind company paranoia firewall and filtering mechanisms. I would like to see KC keeping the state of the tree view in a cookie. So I always get the last view I chose, which in a desktop probably would always be with the tree visible. Been using it on Windows7 with IE (since I'm force to in the office), and Firefox at home. Also on my iPad using Safari and Mercury browsers. Those seem to have slight difficulties scrolling the tree view, but otherwise the KC works quite well on the iPad (iOS 9.3) --Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: IBM Knowledge Centre
>Yes, PDFs can be rough on a mobile. What do you think of ePubs instead? I'm reading PDFs on my iPad all the time. Works great, provided you're using a good app (Apples builtin apps are not my first choice). For PDFs I used to use FileApp and have no swithed to Readdle's "Document 5". Great app with excellent search within the PDF. I don't own a smartphone, so no experience with this type of mobile device. As for ePub format: Whatever IBM chooses, don't abandon PDF! As said elswhere, I'm always downloading PDFs, e.g. all of the z/OS bookshelves and books onto any platform I'll be regularly working on. And lack of IBM Library Reader, I use PDFs. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: IBM Knowledge Centre
>Just out of curiosity, if ePubs of z/OS books provided all the same >functionalities as PDFs (same technical content, same methods for >obtaining/saving, etc.), plus had added benefits such as visual scaling and >accessibility, would you still be so adamant about keeping PDFs? Basically I don't care what format is used, what I *do care* is that I want one format for which there is a reader on just about any platform. I do not want to keep the same book in different formats for different platforms. As a matter of fact, there are PDF readers available on all platforms (at least I now about Linux, iOS, OSX, Windows, Android). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Short description of system address spaces
Thanks. What I imagine is a short descriptive paragraph (two to three sentences) for each AS. I already started with this. I will happily share the doc with anyone interested once its finished (make take a while, though). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: [EXTERNAL] Re: IBM Knowledge Centre
>> What I absoultely dislike is the fact that it does not seem to work well >> with IE >I view that as a plus :) And if IE is mandated at work, it's time to sling the >rez ... :) If only administrators would change their mind and allow us poor IT users to select a different browser and make it the default browser. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Knowledge Centre
Sue Shumway wrote: > I *highly* recommend that all KC users, even IBMers, view it: > http://www.ibm.com/support/knowledgecenter/about/videotour.mp4 .) I just watched that video. Well worth watching. I'm getting to like the new KC more and more. But still I want the possibility to download the books for offline reading. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Which fonts are being actually used?
On 03/24/2014 07:16 PM, retired mainframer wrote: I don't know VPS but on my system (AFP and PPFA) all the used fonts were specified in the various PAGEDEFs we used. That might be a place to start. You don't have documents generated by AFP renderers such as ISIS Papyrus, HP Elixier, etc? With those the fonts used are specified on the indivicual page. No PAGEDEFs are used. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Which fonts are being actually used?
I don't have access to VPS documentation, so I don't know if VPS offers a suitable exit. With PSF, I'd try with a Ressource Management exit (exit 7) which can ask to receive control when fonts are loaded. The exit would then write information about fonts being used to a data set which can be analyzed later. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: ISPF dynamically allocating dataset with DISP=OLD?
Was it really some ISPF/PDF function or could it have been some ad-on? FileAid/MVS does an OLD enqueue on the data set even if you're editing a member thereof. You may change this but you can easily forget to do so.-- Peter Hunkeler Von: Lizette Koehler An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: ISPF dynamically allocating dataset with DISP=OLD? Datum: 04.04.14 03:53 Did they compress the dataset in ISPF 3.4? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Chase, John > Sent: Thursday, April 03, 2014 10:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: ISPF dynamically allocating dataset with DISP=OLD? > > Hi, List, > > z/OS 1.13 at RSU1312. The other day, a user "did something" in ISPF that caused > allocation of a Production JCL library to his TSO session with DISP=OLD instead of > DISP=SHR, causing a "hiccup" in batch processing when the scheduler was > "locked out" for a few seconds. So far, we have not been able to replicate "locking > out" another user at the dataset level via any combination of manipulations using > (primarily) ISPF EDIT. > > Here's a SMF14 record formatted by DAF (Thank you, Michael J. Cleary!!): > > 014 VOL=volser DD=ISP15297 OPE=15.30.06.51 CRTDT=02045 > EXPDT=0 DISP=Old > BUFNO=16 DSORG=PO RECFM=FB BLKSIZE=7520 LRECL=80 NVOL=1 > CTRI=CYL SQTY=50 > NTU=00582800 NTA=6000 VOL=OPER9A DEVTYPE=3390 NEX=1 > EXCP=4001 STEP=tsoproc > PGM=IKJEFT01 14XF1=192 14CIS=18090271 14TKL=58051 > > The SMF 42-006 that immediately follows: > > 042 006 JDCOD=Close DSTYP=PDS DSFL1=Non-VSAM_fixed_length_records > VOL=volser DSDEV=ccuu > DSBSZ=256 DSIOR=9 DSIOC=7 DSIOP=1 DSION=256 DSSEQ=256 > DSMXR=58 DSMXS=57 > AMSRB=4000 AMSRR=2562 > > The timestamps on those two records are identical down to hundredths of a second, > so maybe the user was running a SuperC search? We can't tell from evidence > available to us today. > > We've tried every combination we can think of with multiple users ISPF EDITing the > same dataset, and the only time we get any "conflict" is if a second user tries to > open a MEMBER for EDIT that is already opened for EDIT by another user; and we > believe that "lockout" at the member level is accomplished via an ENQ named > SPFEDIT.membername or something like that. IOW, we have been unable to > cause a dataset (PDS or PDSE) to be dynamically allocated with DISP=OLD using > any variant of ISPF EDIT. > > Is there any other way within ISPF that an existing dataset can be dynamically > allocated with DISP=OLD? If there is, we apparently have never encountered it > before. > > TIA, > > -jc- > -- 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
AW: Re: need pub to help me with a REXX exec
Something I find very useful which is not widely know: you can activate interactive trace (equivalent to "trace ?i") with TSO command "EXECUTIL TS". Useful when you need to start debugging so where within an ISPF/REXX application. You just proceed through the panels until you are at the point your want to start tracing. There you enter "TSO EXECUTIL TS" and continue with the application in REXX trace mode. Enter "TSO EXECUTIL TE" to stop tracing again. -- Peter Hunkeler Von: Lizette Koehler An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: need pub to help me with a REXX exec Datum: 04.04.14 03:40 John, You may wish to join the TSO REXX list. It is full of people that just love REXX coding. Go to the bottom of this webpage to join http://vm.marist.edu/htbin/wlvindex?TSO-REXX You may also wish to check out RExx-LA http://www.rexxla.org/ Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John Norgauer > Sent: Thursday, April 03, 2014 3:59 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: need pub to help me with a REXX exec > > Can someone point me to a pub that explains how to debug and/or trace a REXX > exec? > > Thanks. > > > > John Norgauer > Senior Systems Programmer > Mainframe Technical Support Services > University of California Davis Medical Center > 1651 Alhambra Blvd > Suite 200 > Sacramento, Ca 95816 > 916-734-0536 -- 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
ISPF START command remains on the command line
I'm at a new employer, meaning working on a new environment. I've got a strange problem with ISPF, I have no clue how to resolve. I'm used to start new ISPF split screen sessions with the START command. When I do this here, a new session is opened as expected, however the START command remains on the command line of the "old" screen. This leads to the effect that I get a "invalid command" when I switch back to the session I initiated the START from. Any help on what might cause this is much appreciated. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: ISPF START command remains on the command line
Spontaneously I would suspect a bad coded ISPF panel (the one the "START" I left/reoccurring on). This is a thought that I had too, but it happens on any panel. I doubt all of the panels have been adversely changed. and review these: COMMAND_LINE_PLACEMENT RESET_COMMAND_LINE_PLACEMENT Not sure I understand what this has to do with my problem. Its not where the command line is, but that the command line does not get cleared. Anyway, thanks for the ideas. -- Peter Hunkeler Von: Elardus Engelbrecht An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: ISPF START command remains on the command line Datum: 09.04.14 15:30 Thomas Berg wrote: >Spontaneously I would suspect a bad coded ISPF panel (the one the "START" I >left/reoccurring on). Indeed. Or look at 'ISPF Settings and Options' dialog. If the command line still stays there, have a look at ISPCCONF and review these: COMMAND_LINE_PLACEMENT RESET_COMMAND_LINE_PLACEMENT HTH! 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
Am 09.04.2014 16:53, schrieb Gerhard Postpischil: I'd add 4) - many modern control units have diagnostic capability that allows unrestricted hardware access to the drives. If yours do, you'll need physical access controls. I first ran into this when we got our first string of Hitachi 3380s. The C.E. wanted a telephone line so he could service the units remotely; I had to educate management that that would allow uncontrolled access to customer data. True but not only related to the ERASE function. It applies to deleted as well as non-deleted data. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF START command remains on the command line
Am 09.04.2014 20:12, schrieb Duffy Nightingale, SS: I always split the screen by putting the cursor where I want the split, then press PF2. No command needed. Well actually PF2 usually has the command "SPLIT" assigned. So there is a command as well. "SPLIT NEW" would be similar to "START" in that it starts another (up to 8, that will increase with z/OS 21., right) split screen session. However, "SPLIT NEW" does not allow another parameter to directly jump to some place in the new session (IIRC). And, I don't want to bother changing numerous KEYLISTS on numerous systems from "SPLIT" to "SPLIT NEW". -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF START command remains on the command line
Am 09.04.2014 20:18, schrieb Tom Marchant: That only lets you have two splits. Not if you change "SPLIT" to "SPLIT NEW". -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 abend on old assembler program when upgrading to z/OS 1.13
Am 09.04.2014 20:59, schrieb Pommier, Rex: _9750 -8 4710 C04ABC74(,R12)BO _9754 -4 5830 0208L R3,520 _97580 D503 3000 C172 CLC 0(4,R3),370(R12) The program loads R3 from address 520 (208x) which is in the PSA. That field is documented as 520 (208) ADDRESS 4 PSAPCCAV - VIRTUAL ADDRESS OF PCCA It loosk as if the PCCA had been moved to 31bit storage in z/OS V1.13. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 abend on old assembler program when upgrading to z/OS 1.13
Just found this in the V1.13 Migration manual: *Description:* In parmlib member DIAGxx, you can specify the virtual location of the LCCA control block (mapped by the IHALCCA macro) or the location of the */_PCCA_/* control block (mapped by the IHAPCCA macro) to be used when a CPU is brought online. Before z/OS V1R12, if the IHALCCA or IHAPCCA structures specified on the CBLOC VIRTUAL24 or VIRTUAL31 keyword of DIAGxx did not specify either the 24-bit (VIRTUAL24) or 31-bit (VIRTUAL31) location, the default location for the LCCA or */_PCCA_/* was in 24-bit virtual storage. Beginning with z/OS V1R12, the default location for the LCCA and */_PCCA_/* is now in 31-bit virtual storage if you do not specify VIRTUAL24 or VIRTUAL31 for the structures IHALCCA and IHAPCCA. If only one standard processor is online during the IPL, the LCCA and */_PCCA_/* of the IPL CPU will be in 24-bit storage regardless of the specification. If there is more than one processor, and DIAGxx permits it, you'll have the LCCA and */_PCCA_/* in 31-bit storage. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: S0C4 abend on old assembler program when upgrading to z/OS 1.13
>Who'd have thought that the number of CPUs online would affect the default >virtual location of LCCA and PCCA? Sometime there are reall funny costructs. However there sure must be a good reason for this since code had to be written to handle it. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF START command remains on the command line
>Lots of great suggestions in this thread. Use what you like and ignore the rest. I fully agree. Nevertheless, I do have my own great ways to jump around without the need to take my fingers off the keyboard (no mouse needed). I'm using PCOM macros. My problem is not how to get around but to understand why the command is not clear in the command line. Still investigating... Thanks for your suggestions -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Testing (was 'Tesing') A SubSystem Initialization Routine
How about running your initialization routine from a job or started task instead of via SSI definition? You would need a small driver that calls your init routine from that job or STC. You could even write a small program to cleanup the environment before rerunning the init job/STC. Once you're happy with the code, add it to the SSI definition so that it will be run automatically. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: PSF Issue
Mark,You may want to try on the AFP-L list (http://listserv.uga.edu/archives/afp-l.html). AFP and Printer experts hang out there. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: DFsort and zIIP
>DFSORT can use zIIP on behalf of DB2 utilities, but not otherwise. Here's >more information: > >At this time, IBM has no plan for enabling DFSORT to exploit the system z9 >Integrated Information Processor (zIIP). IBM realizes DFSORT remains a >prominent component of our customers' batch workloads. However, the >added controls that would need to be implemented in order to maintain our >high standards for performance, reliability and system integrity are not >justified in view of estimations that there is a low offload potential and >the value to clients may be marginal.[snip] Interesting statement. I seem to remember that SyncSort offers an Add-On package that allows certain SyncSort processing to be offloaded to zIIPs. The above statement suggest that SyncSort's perfocmance is suffering from using zIIPs (simplified and exagerated, I know). Also "IBM Sort for DB2 for z/OS" (can't remember the exact name), is offloading to zIIPs, if I remember correctly. This procuct is based on SyncSort code as far as I understand. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Exclusive ENQ on a TSO logon procedure
>If a user logs on, it is JES2 that reads the logonproc from PROCLIB, which it >already has allocated (as you >mentioned). Kind of a chicken and egg problem: >how can a user logon without having read the logonproc? >Kees. > >Oh yeah..You are right.. . That explains why User C was able to log on . Thank >you Kees ... JES2 is usually defined with NODSI in the PPT (SCHEDxx) and does not hold an ENQ on the data sets it has allocated. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Exclusive ENQ on a TSO logon procedure
​>As as aside on this, as I understand it, this only applies to data sets >allocated via JCL. That is, if you allocate a PROCLIB inside the JES2PARM >(see below), the DSNs listed do have, and keep, the normal allocation (SHR >as I recall when JES2 does the DYNALLOC). This is true but the description of SCHEDxx explicitly mentions that JES2 is honouring the DSI/NODSI setting when doing its dynalloc. >Also, if I remember correctly, when you specify NODSI, what actually >happens is that the data set _is_ enqueued when you do the START command, >but soon after (during the processing of the PPT entry?) the initiator will >release the ENQ. That is, if you have an STC defined with NODSI, but >something else has a DSN in the JCL "tied up" with a DISP=OLD type >allocation, then the START command will still get A "waiting on data sets" >message and will not be started until the DSN is available. ​ Again true, but I did not mention it because (in normal situations) JES2's ENQs would have been released before any other job or TSO user can be started. Of course, if you ABEND JES2 and restart is, the situation is different. And it also does not help with $ADD PROC. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: DFsort and zIIP
>You are correct that the ZIIP dispatcher is not as sophisticated as the >regular dispatcher. I dare to contradict, not intending to question you expertise. It is my understanding that there is only one dispatcher in MVS. It handles work on the CP WUQ as well as work on the zIIP WUQ. The reason for the wait time mechanism is explained in Init&Tuning Ref, IEAOPTxx. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Interface to query length of storage allocated with CEEGTST LE service
When using LE service CEEGTST to allocate a piece of heap storage, the length is provided by the caller of the service and the address of the storage is returned by the service. To free that storage CEEFRST is called. Only the addressof the area, as returned by CEEGTST, has to be passed to the service. LE remembers the length of the area. Is there an interface or any other documented way to get the length of an area at a given address? -- Peter Hunkeler -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Interface to query length of storage allocated with CEEGTST LE service
> I very much doubt it. Yeah, me too. But I thought I might be missing something and better ask. >I'm curious; what will you do with this info if it is available? I'm asking because I have been asked by our middle war guys. Our applications are required to use our own middle ware service routines for certain functions instead of HLL or LE or CICS services directly. (This is not part of the discussion.) They wanted to know if there is a possibility to retrieve the length somehow instead of remembering it somewhere in own data structures. (I don't know more details about the why and what for.) Thanks for the hint regarding LE possibly rounding up. Since I do not know details what they intend to do, I cannot say if this rouding is important for them. But I'll pass it on. Thanks -- Peter Hunkeler -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: DFSORT and zIIP
>For DB2 Sort for z/OS, zIIP -- Peter Hunkeler >exploitation makes technical sense. For DFSORT -- except for exploiting >zIIPs on behalf of DB2 utilities and in other ancillary ways -- it doesn't >seem to make technical sense. All this speciality engine thing never made any *techincal* sence to me at all. It's a pure financial thing. >Maybe in the future, as the technologies change and evolve, it will. I'm longing for the day when also the zIIPs disappear again and IBM has found a better way to charge software license fees. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Setting dump options for SVC dumps taken by StarTool DA-Batch?
We're using both SmartRestart as well as StarTool DA. As far as I understand, SmartRestart asks StarTool DA , The former recognizes the ABEND (0C4 in this case) and it recognizes that StarTool DA is also present. Since there is a //SYSUDUMP DD card in the jobstep, it sks StarTool to schedule an SVC dump. The dump is fine with the exception that my beloved System Trace is not present, because it was not requested via SDATA option. Does anyone know how I can change that? System DUMP options for SYSABEND, SYSMDUMP, and SDUMP have the SDATA(...TRT...). Only SYSUDUMP has Just SDATA=(SUM), but that should not apply in our case. Before you ask: No I have not asked the ISVs since I'm not in the position to ask them. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Resource Group Limits as a cost containment method?
>Would it be worth investigating setting a resource group limit for the batch >service class(es) to hold the total 4HRA down as a cost-saving measure, or are >resource group limits going to cause more trouble than they are worth? At month ends, we were hitting the Group Capacity Limits repeatedly, and the systems were capping when the online work started in the morning. During the night and early morning before online, batch had a lot of capacity to use and it did use it. We introduced Resource Groups to limit what batch can consume in the early morning. The goal was to bring down the R4HA until when online start, and thereby make sure we will not get into capping. We're using Resource Grpups with great success since March this year. No negtive impact seen so far. We defined a couple of WLM policies with different Resource Group Max values, so we can easily and quickly adjust the amount of capacity batch can use. We're using type 2, i.e. percentage of LPAR capacity. We're using policy overrides to override the Resource Group MAX value instead of changing the Resource Group assignment in the Service Classes. In other words, there is only one Resource Group and it is assigned to all batch Service Classes (except from an "emergeny" class). The RG MAX value is different in each Service Policy. The later are named someting like RG_B10, RG_B12, etc. The digits represent the percentage assigned. In the base policy, the RG does not have a MAX value. MIN values are always empty (0). -- Peter Hunkeler -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Setting dump options for SVC dumps taken by StarTool DA-Batch?
>> Does anyone know how I can change that? System DUMP options for >> SYSABEND, SYSMDUMP, and SDUMP have the SDATA(...TRT...). Only >> SYSUDUMP has Just SDATA=(SUM), but that should not apply in our case. > >What is displayed by the D D,O command on your system? The above paragraph is a summary from the D D,O command and I thought it would be clear. It seems, it is not. Sorry. Yes, from the display one would assume TRT is active for SVC dumps. However, viewing the flags withing the dump does *not* show TRT as part of the options selected. This is what lets me think that StarTool DA is specifying its own SDATA options when requesting the dump. >Under IPCS, what does VERBX IEAVTSFS display for Partial Dump Reason Codes? I'm at home now, but will check the above tomorrow. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: System symbols in batch JCL
>3 // SET D=&LDATE Without verifying exactly with the manual, I seem to remember that it talks about old and new date and time symbols. &LDATE is an old one and this does not work (I don't know if this is documented somewhere). &LYYMMDD is a new symbol and this one is working with batch JCL. Try using &LYYMMDD and &LHHMMSS (I hope I remember the names correctly). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: System symbols in batch JCL
>I gotta ask, how on earth have you guys survived all these years >without system symbols support enabled in JES? For production jobs, I guess the schedulers jumped in. They long (always?) supported symbols that will be resolver at submit time. A couple of date/time symbols and even better date time functions help even more. And they long (always?) supported these symbols in instream data (DD *). For those jobs I doubt anyone has any need for the system symbol support introduced with z/OS V2.1 Peronal jobs are a different story. It has always been a great pita that there was no system symbol support for batch jobs, and for batch and STC, that there was no support for system and JCL symbols in instream data. I personaly have quickly started to use instream support, and to a lesser extent, system symbols in my own jobs. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Resource Group Limits as a cost containment method?
>I am not quite sure what you are aiming at. Speaking for our environment and our paint points, only. It is true that the cost is under conrtol with Defined Capacity or Group Capacity Limit set. The problem is the huge amount of capacity that you might loose once your system is capping. If this happend during the batch window, that's under control and not really an issue. However, the online workload does not cope well with capping, this is the period we want to avoid capping as best as we can. Proper Service Class make sure important work gets resources first. But if there is no online such as during the batch window, batch takes it all and thereby is driving the R4HA towards the Defined Capacits or Group Capacity limits, leaving no spare for the online window. Service Classes cannot limit resource access when spare resources are available. Resource Groups can, this is what they have been invented for. So at critical times such as month ends, we're limiting what batch can take, effectively a kind of capping within a z/OS instance but only for certain types of workload, i.e. batch. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: Setting dump options for SVC dumps taken by StarTool DA-Batch?
>If they specify the SDATA NODEFAULTS option, that would cause >the options added by IEACMD00 to be ignored. I've displayed the flags again: - "Ignore CHNGDUMP parameters" was set in SDUFLAG1 - "NODEFAULTS" was set in SDUSDAT3 Sigh. VERBX IEAVTSFS tells me partil dump reason codes are all zeroes. So I'm left with the hope that SmartRestart or StarTool DA (whichever schedules the dump) can be told to include the trace table in the dump request. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
S0C4-11 abend caused by BASSM to address with all X'00' bytes
I'm confused. Can I not see the obvious? We've got an S0C4-11 abend in a batch job. The last instructions seem to be L R15,x'90'(,7) BASSM R14,R15 R15 has the address that is seen in the PSW in the dump. The storage at this address *is* in the dump, and it contains a couple of X'00'. How can the storage be in the dump when the abend code suggests it is not even getmained (S0C4-11)? Why is this not an S0C1 (operation exception caused by X'' at the PSW NSI address)? The PSW in enabled, problem state, key 8. The storage pointed to by R15 is in SP 1, key 8. Any hint what I'm missing? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes
The storage R7 point to, and the storage at offset x'90' is in SP251 key 8. It is part of a load module. The fullword at R7+x'90' is the value seen in the PSW, so both the L as well as the BASSM have been executed. The program fails when the CP is accessing the instruction at the PSW's NSI. The storage at this address is a couple of x'00', and the storage is in SP1, key 8. If anyting was allocated but not accessible, a S0C4-4 would occur, not an S0C4-11. --Peter Hunkeler -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: 22 July, 2016 15:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: S0C4-11 abend caused by BASSM to address with all X'00' bytes I'm confused. Can I not see the obvious? We've got an S0C4-11 abend in a batch job. The last instructions seem to be L R15,x'90'(,7) BASSM R14,R15 R15 has the address that is seen in the PSW in the dump. The storage at this address *is* in the dump, and it contains a couple of X'00'. How can the storage be in the dump when the abend code suggests it is not even getmained (S0C4-11)? Why is this not an S0C1 (operation exception caused by X'' at the PSW NSI address)? The PSW in enabled, problem state, key 8. The storage pointed to by R15 is in SP 1, key 8. Any hint what I'm missing? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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
AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>What are the full contents of the 128-bit PSW? What's the 64-bit TEA value? I got a CEEDUMP and an analysis from StartTool DA. Both tell me the failing PSW is478D0400 A31A7BB8 Looking at the SVC dump at the PRB/XSB which is now producing the SVC dump (WLIC is 00020033), I see: XSB+00E0 PSW16 47850400 8000 231A7BB8 Seems to match. Unfortunately, there is no LOGREC entry in the dump for this error, the system trace table has not been dumped (Grrr...), and there is no SDWA in the dump. I'm lost how to find the TEA in this case. --Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>How about the TRNE and BEA fields in that same XSB? I seem to remember to have had a look a the BEA address and it matched with the BASSM. Will double check. on Monday when back in the office. Will also have a look at the TRNE then. There is LE, Smart/Restart and StarTool DA which actively try to get their say. As long as I don't understand where the S0C4-11 comes from, I don't trust the information I see in the dumps. It's too foggy which code does what and when during recovery. We're trying to repoduce the case in test so I can switch off all those little (sometimes useless) helpers. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>If you show the exact information from the dump, rather than your >interpretation of that data, there is a better chance that someone will be >able to see something that you didn't. I'll happily show any data you ask me specifically. I would not know what to post otherwise; It simply too much data. I'm not asking for help to solve that actual problem that application has had and which caused the dump. I'm looking for help to undestand why we get the S0C4-11 when I had expected an S0C1. I trust once I understand this, I'll be able to continue debugging the problem. It's embarrassing how rusty my dump reading skills have become. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>The most likely explanation is that the target address of the BASSM >was not GETMAINed storage at the time of the abend (causing the >0C4-11 abend), but was subsequently GETMAINed and used before the dump >was initiated or as part of the dump processing. Yes, I had thought about this possibilty as well. The storage where the PSW NSI point to seems to be part of a chain of 4k areas. I see what looks like forward and backward pointers near the beginning of each 4k area. I also see the name of some of the applicaition modules that are loaded, as well as the lliters PCONTROL in each of the blocks. Some bytes before the first such block, there is the literal HANC, which indicates this might be LE heap storage. For all this, I thought the storage must have been there before the S0C4, but of course this linked list can as well have been built as part of Smart/Restart or StarTool analysis. But is seemed unlikely to be that tools bilt to analyze failures would tell me false information. But again, who knows. If I only had the system trace. It would all be so much easier. I cannot understand how someone coding an SDUMP macro can leave away TRT and explicitly specify that dump defaults and change dump options shall be ignored (seen in the SVC dump, dicussed in a separate thread). Thanks for your help so far. I'll restart posting on Monday, if I have new questions or new information with wich you could help me. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>Just curious that the PER bit is on. Was someone running a SLIP of a >PERish sort? Any chance of a dump or trace from that, or is the toy >dump all you have to work with? Made me wondering as well, but I have not checked the SLIPs yet. I doubt there is a SLIP for this job, so the SLIP is set to be not limited for the target job(s), only. Bad, IMHO. I did check if there is another SVc dump from that time around which could have provided me the missing system trace, but Murphy made sure there is none. So yes, for the time being I'm left with the toy dumps. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: System symbols in batch JCL
If anyone is still paying attention, my question lingers. Is CLASS A always used for JCL conversion? Just because it's first in the list? Is it a defined or default option? If it's always gonna be CLASS A, do I need to 'ALLOW' any other class? The conversion is not done by a class, its done by the conversion code. The CLASS only tells limits and defaults. If you allow SYSSYM on class A but not on class B, conversion will fail to resolve symbols if CLASS=B is coded on the job statement, but will do it for CLASS=A. In your case, the symbol resolution is probably done before something changes the CLASS form A to C. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: Setting dump options for SVC dumps taken by StarTool DA-Batch?
Great! Just the information I was looking for! Now I just need to convince our engineers to actually do it. And yes, I have been debugging using this dump in IPCS. This is how I found out that TRT is not specified in the SDUMP macro. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>You say it's in the load module. Did you violate reentrancy? N, I never do :-) But seriousy, the data being loaded into R15 comes from the load module's storage and this is accessible. The code then seems to happily branch to the address in R15 (the BASSM instruction), i.e. the content from R15 is seen as the PSW's NSI address. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>You provided analysis of some data. If you had provided the data that you used >to arrive at the conclusions >that you did, that would have been helpful. It >may have led to a request for more data, but at least we would >have had a >place to start. You're right. Would have been better to post snippets from the dump in addition to my conclusions and questions. >You've shown the PSW. You haven't shown the data at and before the PSW. Do you >have the ILC? I did not show the data but I wrote that the PSW NSI points to a bunch of x'00'. Sorry this was not clear enough. And I dd not post the ILC because I considered it irrelevant. With a 0C4-11 the NSI points to the failing isntruction itself and this was x''. But I admit, this was again subjective information instead of facts. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes
> These days the PER bit is *always* on, in any serious development/test > environment, because of the ever-present ZAD SLIP in effect. Good hint. I would hope we don't have this active in production (the problem occurred in production). Will check on Monday. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>Oh gawd. This is where I shrug my shoulders and wash my hands of it. I >like SVC dumps with all storage dumped and nice long trace tables. >Anything else is just frustration in a can! I couldn't have said this better. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>Just a thought - >Could the area R15 points to have been allocated by one of those "we'll figure >out your problem for you" >routines after the 0C4-11 and before the dump so >that when you look in the dump they provide it looks like >you should have >gotten an 0C1 rather than an 0C4-11? Yes, Jim Mulder mentioned this already in an earlier post. In the meantime, I believe this really must have been the case. Nobody provided any information that would explain it to meant something else. I had not been involved in debugging cased once others have given up for quite some time. I'm a bit rusty in reading dumps. I just wanted to make sure I'm not missing the obvious. I feel more confidet now. Thanks everybody for your help so far. I suspect the inital cause is some kind of storage overwrite by the applicaiton white hits some other code some time later. The result is what I got; with not hint on what wrote when and where, when it should not have This kind of problem is difficult enough, I don't want to base my analysis and guessing on a dump I cannot trust. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>So why was the page not allocated and what executable code >should have been loaded into it - or is its address corrupted? I don't have a clue yet, but as said in my previous post, I suspect some storage overlay. Results are unpredictable. >(The x'' seems to be left-over garbage.) It is more likely it is fresh storage after the page was initially assigned to newly getmained storage. It will be cleared to X'00' by MVS. If nobody writes before reading it, it is still x'00', i.e. garbage. >BTW Why load offset x'90' on R7 as EP? I don't have clue. The storage where R7 point to belongs to a load module is called SQLBATCH and it seems to belong to Smart/Restart. Not our code. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Interface to query length of storage allocated with CEEGTST LE service
Bill,thanks for your answer. I concur with everything you wrote. I don't know what they intended to do with this if it was available. I doubt they want to do their own storage management. I seem to remember they talked about "statistics" or "bookkeeping", but I'll have to ask for more details. Anyway, I will not suggest to learn this information by scanning undocumented control blocks. It is too dangerous for production use. They will need to keep that information, if realLy required, in their own data. They already keep all kinds of things around. -- Peter Hunkeler Von: Bill Woodger An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Interface to query length of storage allocated with CEEGTST LE service Datum: 23.07.16, 12:47 There is some evidence that the "control information" is stored in the heap itself (see the Usage Notes for "CEEFRST—Free heap storage") and by implication associated directly with the storage allocated. However, it is not documented, and working it out through inspection would be pointless beyond simple interest, as you know. I still can't work out *why* it is wanted. I think some detail on that would help. Generally it won't. be. Specifically it could be See if they can read through this and explain LE heaps back to you correctly. There may be assumptions being made that "storage management" of some type is needed, when probably it isn't. Note, you could ask for a very small amount of storage and if new storage has to be obtained from the OS, an entire "increment" will arrive. So what? Other heap storage requests can be served from that. If there is (genuine) concern about freeing storage (to the enclave or to the OS) it can be done, and even (using FILL) an increment which could otherwise be unavailable due to "fragmentation" can be dealt with. If necessary. For performance *don't release storage to the OS that may be needed again*. Unless you really need to. Really need to, means really need to, not just "I think it would be good to do that, because I always do that in my smartphone app". Don't apply non-z/OS concepts to z/OS. Unless they happen to work, but you have to know. You have to know your application, and how z/OS, LE, and whatever else, are doing things. If the code is all C/C++, there is the chance you write your own, presumably optimised, heap management - see Vendor Heap Management. You can't do everything there, and it is not a way to manage what LE sets up (you have to do everything yourself) so doesn't answer the original question by providing some "map", but if they really, really need to manager their own storage, it is a possibility. -- 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
AW: DFSMSdss address spaces started by DFSMShsm
>SDSF display > >DFHSMDFHSMDFHSMSTC06087 DFHSM >IEESYSAS DSSFRB01 IEFPROC STC06108 #STC > >but the priority of the IEESYSAS is lower than the one of DFHSM > >SDSF display > >DFHSM24 SYSTEM SYSSTC >IEESYSAS 24 STC STCLOW Have you tried to classify those address spaces in WLM subsystem STC using TN DSSFRB* and assign them to SYSSTC? Do you explicitly assign TN IEESYSAS to STCLOW, or is this just the detault service class for STCs? In RACF, you use profiles in the STARTED CLASS of form xxx.yyy. I played with them and ASCRE/START ans IEESYSAS while ago, but can't find the result at the moment; will have to dig a bit. I seem to remember that depending on how exactly DFHSM starts those address spaces, they will match a STARTED CLASS profile IEESYSAS.DSSFRB*, or not. Have you tried yet? If so what did you try and what did not work? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
SID 0159 PINS. D46C AX... 007A +00D6
PASID 0159 BEA.. 019DA75APSW16
+00F0 OPS16 4704 8000
1B7335FEORPSW 470C 9B7335FE +0108 R108.
*** BEA from XSB of current PRB is:
BEA.. 24D90BE0 LIST 24D90BE0. ASID(X'0159') POSITION(X'-10')
LENGTH(X'0800') INSTRUCTION24D90BD0 | 5030 71B8 | ST
R3,X'1B8'(,R7)24D90BD4 | 5010 71D8 | ST R1,X'1D8'(,R7)24D90BD8 | 4110
71D4 | LA R1,X'1D4'(,R7)24D90BDC | 58F0 7090 | L
R15,X'90'(,R7)24D90BE0 | 0CEF | BASSM R14,R1524D90BE2 | 58D0 D004
| L R13,X'4'(,R13)24D90BE6 | 58E0 D00C | L
R14,X'C'(,R13)24D90BEA | 980C D014 | LM R0,R12,X'14'(R13) *** PRB
seems to be in recovery processing, since SVC33 has been issued.*** Using
register content from CEEDUMP: GPR7. _DC20 LIST DC20.
ASID(X'0159') LENGTH(X'0800') STRUCTURE+0 DC20. 17C4C3C1
5BC4C3E3 407AF0F1 61F2F361 F0F37AF1 F94BF2F5 |.DCA$DCT
:01/23/03:19.25|+00020 DC40. A3166CD8 A3166CE4 A3166CF0
A3176090 |t.%Qt.%Ut.%0t.-.|+00040
DC60. 0001B060 A3580DD0 DF38 DEE0 A31D8D38
A31B5658 |...-t..}...\t...t...|+00060 DC80.
A319D390 A319D0F0 A31A9E98 A31A9CF0
|t.L.t.}0t..qt..0|+00080 DCA0. A31A95B8 A31A9298
A31A8A78 A31A7BB8 A31A7AC0 A31A61C0 A31A5618
|t.n.t.kqt...t.#.t.:{t./{t...|+000A0 DCC0. A31A2468 A31A22F8
A31A0448
|t...t..8t...|+000C0 DCE0. 0001 00019100 00C78100
231865C0 6AC0
|..j..Ga{...{|+000E0 DD00.
6900
||+00100 DD20.
6F30 E4C44040 |..?.UD
|+00120 DD40 LENGTH(X'20')==>All bytes contain X'00'*** Data at offset
x'90' matches the NSI in the PSW and R15 as displayed in the CEEDUMP: GPR15
_A31A7BB8*** TRNE from XSB of current PRB is: TRNE.
231A7800
--
Peter Hunkeler
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>> It will be cleared to X'00' by MVS. > >YMMV on that... > >"When you obtain storage, the system clears the requested storage to >zeros if you obtain either: > >8192 bytes or more from a pageable, private storage subpool. >4096 bytes or more from a pageable, private storage subpool, >with BNDRY=PAGE specified. I stand corrected. Thanks for remembering me. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
Oopps, I was afraid of that. Does IBM-MAIN allow attachements? Can't remember, but will try. -- Peter Hunkeler *** CEEDUMP data folows: CEE3DMP V2 R1.0: Condition processing resulted in the unhandled condition. 07/15/16 12:12:28 AMASID: 0159 Job ID: J0274722 Job name: P07W04UA Step name: DB2RUN UserID: TWSP0A CEE3845I CEEDUMP Processing started. Information for enclave ZTVXXX00 Information for thread 8000 Traceback:DSA Entry E Offset Statement Load Mod Program Unit Service Status1 CEEHDSP +4A4C CEEPLPKA CEEHDSPUI90017 Call 2 -01BE8FAE HRDRFREA Exception3 . -- Peter Hunkeler -- 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
AW: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
As expected, having the dump information inline did not work out. I'm reposting with an attachement. Hopefully this will work better. In (late) response to Jim Mulder's comment: >How about the TRNE and BEA fields in that same XSB? and Tom Marchant's comment: >If you show the exact information from the dump, rather than your >interpretation of that data, there is a better chance that someone will be >able to see something that you didn't. I'm posting some raw information from the CEEDUMP as well as from IPCS. I have added a few lines of comment starting with "***". In the CEEDUMP part I have shortened the trace back list by deleting some intermediate call information (entries 6-13). I don't want to add an futher interpretation from me. If you still find some time to have a look and post whatever information you might find useful, I would very much appreciate. Thanks Peter -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN *** CEEDUMP information follows * CEE3DMP V2 R1.0: Condition processing resulted in the unhandled condition. 07/15/16 12:12:28 AM ASID: 0159 Job ID: J0274722 Job name: P07W04UA Step name: DB2RUN UserID: TWSP0A CEE3845I CEEDUMP Processing started. Information for enclave ZTVXXX00 Information for thread 8000 Traceback: DSA Entry E Offset Statement Load Mod Program Unit Service Status 1 CEEHDSP +4A4C CEEPLPKA CEEHDSP UI90017 Call 2 -01BE8FAE HRDRFREA Exception 3 HRDRFREA+4396 HRDRFREA HRDRFREA Call 4 IGZCFCC +02FC IGZCPAC IGZCFCC UI19860 Call 5 HRDDBLNK+9C92 HRDDBLNK HRDDBLNK Call ... 14IGZCFCC +02FC IGZCPAC IGZCFCC UI19860 Call 15ZTVXXX00+0A10 ZTVXXX00 ZTVXXX00 Call DSA DSA Addr E AddrPU AddrPU Offset Comp Date Compile Attributes 1 23117AE0 08DA2B60 08DA2B60 +4A4C 20150130 CEL 2 0001 24D90B66 24D90B66 -01BE8FAE 3 231176E8 24D85D48 24D85D48 +4396 20130225 COBOL 4 231174F0 20EDB610 20EDB610 +02FC 20140722 LIBRARY 5 23117078 235F6400 235F6400 +9C92 20160624 COBOL ... 1423115258 20EDB610 20EDB610 +02FC 20140722 LIBRARY 1523115030 23100428 23100428 +0A10 20100129 COBOL Condition Information for Active Routines Condition Information for (DSA address 0001) CIB Address: 231181B0 Current Condition: CEE0198S The termination of a thread was signaled due to an unhandled condition. Original Condition: CEE3204S The system detected a protection exception (System Completion Code=0C4). Location: Program Unit: Entry: Statement: Offset: -01BE8FAE Machine State: ILC. 0002Interruption Code. 0004 PSW. 478D0400 A31A7BB8 GPR0. _24BD7528 GPR1. _DDF4 GPR2. _24D96690 GPR3. _0004 GPR4. _23145460 GPR5. _77FC GPR6. _0001 GPR7. _DC20 GPR8. _009B7028 GPR9. _24BD73A8 GPR10 _009B7008 GPR11 _009B7E88 GPR12 _24D90B40 GPR13 _0001 GPR14 _A4D90BE2 GPR15 _A31A7BB8 FPC.. FPR0. 4EE6ED27 D6668000FPR1. 487F FF00 FPR2. 4264 FPR3. FPR4. 40326E64 05A0FPR5. FPR6. FPR7. FPR8. FPR9. FPR10 FPR11 FPR12 FPR13 FPR14 FPR15 Storage dump near condition, beginning at location: 231A7BA8 +00 231A7BA8 |...
AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>It seems that you branched to a location that is fetch protected and not in >key 8. That would lead to a S0C4-4 not S0C4-11, wouldn't it? >What do you expect to find at 231A7BB8? My guess is that the LE formatter is >showing all zeroes since it cannot access it. The storage is available, otherwise it would be marked as "inaccessible storage". I don't know what to expect at that address, it is not my application, I was merely asked if I could help debugging what seems to be a storage overlay problem. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
Thanks, Ed, I wasn't aware of the *trailing* whilte space behaviour. However, I think apart from that Listserv removes all leading space (and multiple spaces?) and thus also makes reading the dump output difficult. --Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>:>That would lead to a S0C4-4 not S0C4-11, wouldn't it? > >Program Unit: Entry: Statement: Offset: -01BE8FAE >Machine State: >ILC. 0002Interruption Code. 0004 Thanks. I was mislead by the fact the the failure was reported as S0C4 reason 11 in the joblog. Also LE as well as IPCS show the content of the memory at the address in R15 / PSW NSI, and this is key 8 storage. *But* the main purpose of my post was to under how the job can fail with a S0C4-xx when I can see the storage in the dump. The conclusion was (see previous thread) that the "little helpers" must have getmained and gotten storage that was not there (or not in key 8) at the time if the initial error. >I don't know how LE plays that game. A SLIP of the 0C4 would have true >contents. System Trace would also help with this information but it is not in the dump produced by the "little"helpers". Setting a SLIP in production is a not so short adventure trip; and SLIPping for a 0C4 is not trivial as long as I don't have more information what actually happens. I have asked that the job be changed to switch off the 'little helpers' and a SYSMDUMP DD be added. Hopefully I will have more information next time it fails. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>[snip] I would take a closer look at the call position of the COBOL module at >level 3, at position 4396. >The name is HRDRFREA. >>maybe this is all misleading ... I agree with your findings. Module HRDRFREA is calling DSNHLI at this offset. So far nothing special. However, the job runs under control of Smart/Restart that intercepts just about anything, and probably needs to, in order to fullfill it's duties to make the job restartable. I don't know much about the internals or Smart/Restart, but from another case I had to invesitgate, I learned that it is intercepting SVCs like open, close, as well as BSAM/QSAM read/write routines, etc., etc. What makes it worse is the fact that we also use StarTool DA which should be a help in diagnosing appliation problems. Smart/Restart is the first to learn about an exception (or is it after LE?), it recognized StarTools DA is also part of the game. The former then advises the later to take an SVC dump. The later has unfortunate dump options built in its code that request only mininmal content (not TRT, etc.) and forces system dump options to be ignored. Result of all that is misleading information in the dumps. Lack of a system trace, I'm unable to see the real events that happened. I only wanted to understand why a S0C4-11 was reported when I had expected a S0C1. I did not talk about the following so far for that reason. Based on what I know so far, I'm convinced the problem seen is a delayed effect of a storage overlay somewhere else in the Cobol code. Support people identified the current input record, removed it from the input file and the job runs fine. Happened to more times so far. This why I suspect that something with that record leads to false behabiour of the code, such as writing beyond the end of a table. What I also did not mention to anyone so far: I see a single line message from Smart/Restart that says a S0CA (Decimal Overflow) has happended. Not indication where, no dump at this time. Nothing but silence. This was just a bit before the S0C4-11 messages start to show up. I'm hoping for a system trace in the SYSMDUMP that I was requesting to be added to the job (mentioned in a previous post). Kind of seems to be a case liek the one Skip Robinson mentione (S0C7). We'll see. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>You told us that the instruction address where the BASSM goes is correct. No, I told that the address fetched into R15 matches where the BASSM jumped to and matches what is seem in the PSW. >What happens, if you switch off LE dump processing by LE option TRAP(OFF)? I don't dare to ask for this. As said there is Smart/Restart and with my current (limited) understanding of what this does and what it depends on, this would be risky. The application depends on the tool to coordinate sequential file processing with DB2 processing in the case of abends and restarts. I'm hoping for the SYSMDUMP. If that fails, I will take the burden and ask for a SLIP. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
When to use TRNE in the XSB? (was: S0C4-11 abend caused by BASSM to address...)
>>>What are the full contents of the 128-bit PSW? What's the 64-bit TEA value? >> >> I got a CEEDUMP and an analysis from StartTool DA. Both tell me the >> failing PSW is478D0400 A31A7BB8 Looking at the SVC dump at the PRB/ >> XSB which is now producing the SVC dump (WLIC is 00020033), I see: >> XSB+00E0 PSW16 47850400 8000 231A7BB8 > >How about the TRNE and BEA fields in that same XSB? The XSB has: TRNE. 231A7800 BEA.. 24D90BE0 This translation exception address does not seem to match where he PSW NSI points to. From the previous discussion the conclusion was that it is most likely the storage pointed to by PSW NSI had not yet been getmained at the time of the original error, but later during recove3ry processing but before the dump was taken. But shouldn't I expect to see the PSW NIS address in the TRNE field of the XSB? In other words, what does the TRNE field tell me a) in general, and b) in this case. When is the TRNE field in the XSB updated? The corresponding PRB seems to contain similar contradicting information in fields RTPSW1 and RTPSW2: RTPSW1... 478D0400 A31A7BB8 RTPSW2... 00020011 231A7800 What can I learn from this? How do I properly use these fields in dump analysis? More information from the dumps can be found in the attachement (same as attched in the original discussion). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN *** CEEDUMP information follows * CEE3DMP V2 R1.0: Condition processing resulted in the unhandled condition. 07/15/16 12:12:28 AM ASID: 0159 Job ID: J0274722 Job name: P07W04UA Step name: DB2RUN UserID: TWSP0A CEE3845I CEEDUMP Processing started. Information for enclave ZTVXXX00 Information for thread 8000 Traceback: DSA Entry E Offset Statement Load Mod Program Unit Service Status 1 CEEHDSP +4A4C CEEPLPKA CEEHDSP UI90017 Call 2 -01BE8FAE HRDRFREA Exception 3 HRDRFREA+4396 HRDRFREA HRDRFREA Call 4 IGZCFCC +02FC IGZCPAC IGZCFCC UI19860 Call 5 HRDDBLNK+9C92 HRDDBLNK HRDDBLNK Call ... 14IGZCFCC +02FC IGZCPAC IGZCFCC UI19860 Call 15ZTVXXX00+0A10 ZTVXXX00 ZTVXXX00 Call DSA DSA Addr E AddrPU AddrPU Offset Comp Date Compile Attributes 1 23117AE0 08DA2B60 08DA2B60 +4A4C 20150130 CEL 2 0001 24D90B66 24D90B66 -01BE8FAE 3 231176E8 24D85D48 24D85D48 +4396 20130225 COBOL 4 231174F0 20EDB610 20EDB610 +02FC 20140722 LIBRARY 5 23117078 235F6400 235F6400 +9C92 20160624 COBOL ... 1423115258 20EDB610 20EDB610 +02FC 20140722 LIBRARY 1523115030 23100428 23100428 +0A10 20100129 COBOL Condition Information for Active Routines Condition Information for (DSA address 0001) CIB Address: 231181B0 Current Condition: CEE0198S The termination of a thread was signaled due to an unhandled condition. Original Condition: CEE3204S The system detected a protection exception (System Completion Code=0C4). Location: Program Unit: Entry: Statement: Offset: -01BE8FAE Machine State: ILC. 0002Interruption Code. 0004 PSW. 478D0400 A31A7BB8 GPR0. _24BD7528 GPR1. _DDF4 GPR2. _24D96690 GPR3. _0004 GPR4. _23145460 GPR5. _77FC GPR6. _0001 GPR7. _DC20 GPR8. _009B7028 GPR9. _24BD73A8 GPR10 _009B7008 GPR11 _009B7E88 GPR12 _24D90B40 GPR13 _0001 GPR14 _A4D90BE2 GPR15 _A31A7BB8 FPC.. FPR0. 4EE6ED27 D6668000FPR1. 487F FF00 FPR2. 4264 FPR3. FPR4. 40326E64 05A0FPR5. FPR6. FPR7. FPR8. 000
AW: Re: codepage restrictions on IBM applications
>It's worse than that. One may safely use those characters that are called >in manuals Alphabetic, Numeric, or Special. They're enumerated. all others >are considered Invalid. Alphabetic does *not* include lower case. I doubt this is still correct information. After all, even z/OS base components issue WTOs in mixed case. ZFS is one that comes to my mind, and I'm pretty sure there are more but I can't name them without looking up. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
