Strange issue with SDSF main panel

[Barbara Nitz]

I have a strange issue with the ISPF main (first) panel. I have added 
permission to view the APF list:

pe ISFCMD.ODSP.APF.* cl(sdsf) id(grpname) ac(r) 

and I have refreshed the raclisted sdsf class. I expected the APF command to 
show up in the ISPF main panel once I call ISPF. It does NOT show up. 
LOGOFF/LOGON (just to be safe) did not help, either.

A user in grpname can issue the APF command without any error. Once that user 
leaves the APF command, it is shown correctly on the primary panel. Leaving and 
reentering SDSF produces the same behavior: Only when the user has already 
issued the APF command is it getting shown.

z/OS is 2.3, the behavior occurs on different sysplexes at different 
maintenance levels. The latest level is RSU1812. No ICH408I when running with 
sectrace on.

To make matters even more strange: My colleague had used the APF command 'at 
work' successfully (not seeing the command on the main panel, but being able to 
execute it). Then, from home, she got 'authorization error', the same one one 
gets when issuing a command that one isn't authorized for. We even used three 
different 3270 emulators, just to prove that it is not an emulator issue.

Does anybody have any idea what I might be doing wrong with the definition? It 
might stare me in the face and I just don't see it.

Barbara

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

Re: Strange issue with SDSF main panel

[Barbara Nitz]

Again: The APF command is NOT failing, it 'just' does not show on the main 
panel! It only shows *after* the APF command was *successfully* executed! And 
then only for as long as I stay within that session.

With the exception of 4 userids, *everybody* is in ISFUSER, which doesn't mean 
anything because the authorized functions are explicitly enabled via RACF. The 
LNK command shows up just fine. GROUP.ISFUSER.** and ISF.CONNECT.**  are 
enabled/defined for the group in question.

I just defined a new (test) user and connected it to a group known to work, and 
the APF command is executable there without problem, but also does not show up 
on the primary panel until the command has been successfully executed once in 
that SDSF session. Again, the LNK command shows up fine before and after 
execution.

If I permit the group to the LINE command (just to test something else), it 
also shows up on the primary panel.

Barbara

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

Re: Strange issue with SDSF main panel

[Barbara Nitz]

>Are you using the default panel ISFPCU41? Has anyone modified it?
Vanilla ISPF/SDSF, no usermods, and the panel is always named ISFPCU41.

>How are you invoking it?  Like this?PGM(ISFISP) NOCHECK NEWAPPL(ISF) 
>SCRNAME(SDSF)
Exactly like this: PGM(ISFISP) NEWAPPL(ISF) SCRNAME(SDSF) NOCHECK

>I skip the SDSF primary most of the time by adding command table entries like 
>these:

We already have an ungodly number of direct calls for a lot of (ISPF) panels, 
sometimes interfering with isrddsn commands,  mostly because the panels 
sysprogs need are buried much too deep within layer upon layer of panels built 
on top. I just don't want to deal with even more direct calls. So it is 's', 
and then whatever command is needed next.

Barbara

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

Re: Strange issue with SDSF main panel

[Barbara Nitz]

>How many lines in your ISFPCU41?
541 :-) with the copyright by Rocket Software. But then, the primary panel is 
one column only these days (which took some getting-used-to).

>Ungodly? :-)   I have 153 entries and almost never issue =blah.blah.blah.blah
The problem is that many of the entries we have are probably obsolete, but 
cleaning it up has been a low priority issue (as in: it may or may not get 
done).

Barbara

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

Re: The 64-bit version of LOOK from CBT File 264 is finally out

[Barbara Nitz]

On Thu, 4 Apr 2019 20:33:36 +0300, Binyamin Dissen  
wrote:

>What does this give over IPCS of ACTIVE?
>
My question exactly, too.

>Joseph Reichmann answered: "Going thru control blocks specially if there is 
>eyecatcher and it formats it
>Makes it real easy to go thru control blocks "

Well, IPCS does that, too. There must have been quite a bit of work done to 
allow more of the formatters to work now on active storage.

And IPCS makes sure that you are *permitted* to look into another address 
space, thus protecting an address space from prying eyes (think hacker). Does 
LOOKN take care of that?

Regards, Barbara

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

ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Barbara Nitz]

I know we've been through a few iterations of this, and I still have questions:
We had one offender that was using a key=8 CADS. They have since provided a 
release where they use a system key for their CADS, and that release has been 
installed on all sysplexes/systems. 

I was really astonished when the health check *still* complains about user key 
common storage. We have been running with ALLOWUSERKEYCSA(NO) just about 
forever and had this one offender which got remedied dynamically *after* the 
last IPL. I spent the past two days over SMF records, and while the audit flag 
is mostly on, the only time I saw one of the other flags on (thanks MXG!) was 
exactly for that one, now fixed offender. Every other SMF30 records with a bit 
on in the flags section  does NOT at the same time have the audit flag on, so 
according to the doc that record doesn't count as usage.

Q1: What exactly turns the audit flag on or off (leftmost bit in the flag byte)?

Q2: Is it true that the health check actually checks back to the time of the 
last IPL and reports on that? That would fit with the fact that the production 
system has the check run successfully. But that system was IPL'd after the 
offender got fixed.

Thanks in advance, Barbara

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

Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Barbara Nitz]

Hello David,

parm(new) did the trick! This bit of information must have been buried in all 
the RUCSA stuff that I skipped over because it doesn't apply to us.
We don't have oa56180 applied yet, so that explains why the audit bit wasn't on 
in some cases.

I feel much more confident now to implement allowuserkeycads(no) and NUCLABEL 
ENABLE(IARXLUK2) to prevent usage on all systems.

Thanks a lot, Barbara

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

Re: ibmvsm/ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM

[Barbara Nitz]

Hi Bruce,

>I have the same query open with IBM at the moment.
Well, it helps that I am not alone with that question. :-) 

>If you could provide an example of a RESET command I would most appreciate.
I didn't use it. All I did was go into sdsf and then scroll to the extreme 
right of the health check line. There is the parm for each check. I just 
overtyped it with what David specified. On pressing return the check moved from 
the top of my list (I have them sorted by severity) to the alphabetical place 
where it belongs, I didn't even have to refresh the check.

I read over the apar text of oa56180. I didn't see that it talks about 
correcting the audit flag not being set correctly. I must have again overlooked 
something.

Regards, Barbara

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

Re: MVS master consoles

[Barbara Nitz]

>Hi.  I'm learning some things about MVS consoles.I have both the PD 
>console (SYSCON - aka Operating System Messages task on the HMC) and a 
>local 3270 console (named MVSMAST) active.  Both have all routing codes 
>assigned.  This is in a virtual machine, so SYSCON works with the #CP 
>VINPUT VMSG command and displays line mode output.

I am assuming that SYSCON is the operating system messages console and MVSMAST 
is the 3270 console interface that can be started on the HMC that acts like a 
traditional MVS master console. See below.

From a z/OS point of view there is no 'master console' necessary anymore. z/OS 
happily runs without any 3270 console (local non-SNA) attached these days since 
z/OS 1.6 ore 1.8 (when console restructure was done). That being said, without 
a 'channel-attached master console' the NIP messages during IPL automatically 
go to the operating system console until the point in the IPL when the console 
address space becomes active. At that point all messages are either hardcopy 
only or go to the HMCS console if it is active. I think if the HMCS is active 
at NIP that NIP messages go there instead of the SYSCON.

The 'operating system messages' console needs to be explicitly activated after 
NIP (v cn(*),activate) even if you can still see the NIP messages there. It 
should not stay active for long (v cn(*),deactivate) because it uses the SPI 
which is comparatively slow and could cause problems in the console address 
space (like WTO buffer shortages back in the days when customers were able to 
force CONSOLE to a dispatching priority of 9F instead of FF). Besides, the 
health checker will nag you to inactivate the SYSCON.

The HMCS console acts like a normal MCS console once it is opened (with a 
rather clumsy keyboard interface - the PFKEY-definitions don't really work, and 
the enter key is NOT ctrl). Closing the 3270 window will simply deactivate that 
console without any problems.

If your MASTCON is defined in CONSOLxx with a UCB number then that is a regular 
MCS console (and knowing almost nothing about VM) and acts like a 'master 
console' of old. If that console gets inactivated via some VM command, then 
z/OS will just mark it as inactive and go on it's merry way until it is 
explicitly reactivated from within z/OS (v xxx,console possibly after v 
xxx,online). If MASTCON is defined in the IODF as a NIP console and it is 
active at IPL, it will get all NIP messages and all messages after NIP.

>Will both receive all messages and can either one respond to system action 
>messages?
If consolxx has the appropriate statements (here are mine from our sandplex):
CONSOLE DEVNUM(SYSCONS) INTIDS(Y) LEVEL(ALL) UNKNIDS(Y)
ROUTCODE(1-10,12-128)  
CONSOLE DEVNUM(HMCS) NAME(HMCS&SYSNAME.) AUTH(MASTER) MSCOPE(*)
INTIDS(Y) LEVEL(ALL) UNKNIDS(Y) ROUTCODE(1-10,12-128)  
PFKTAB(PFKTAB1)
then all messages except routcode 11 will appear on these two consoles. RC11 
has been excluded because it is a performance hog and z/OS health checker will 
nag you to remove it from being displayed.

If your MASTCON has a similar console statement with DEVNUM(ucb) then it is not 
the HMCS that I talked about earlier. Same things apply for the routing codes.

Action messages appear coloured on both the HMCS and a regular MCS console 
depending on their descriptor code (unless there are MPF exits that change the 
DC and possibly the routcode). They are shown on the SYSCON only if it had been 
explicitly activated before the message was issued.
Wait state messages (synchronous destination WTO) definitely appear on the 
SYSCON regardless of its activity state - *if* the MCS console (the one with a 
device number in consolxx) is not active. I believe synchdest messages are 
shown on the first active MCS console z/OS can find. At least that was the case 
until console restructure (and we have run without true MCS consoles for a long 
time now, so I don't have operative experience anymore). When we still had 
active MCS consoles, I seem to remember that they had to be defined a certain 
way because I still saw the wait state messages on the SYSCON - the blinking 
icon 'operating system messages' on the HMC  was my point in time when I could 
re-IPL the system.  

Hope this excurse clears things up a bit. If I got anything wrong, I'm sure Jim 
Mulder or Peter Fatzinger will chime in.

Barbara

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

Re: What is the SDATA option to include above the bar storage for a particular job?

[Barbara Nitz]

>What is the SDATA option to include above the bar storage for a particular
>job?

A while ago, I had asked the same question because my dump was missing 
above-the-bar storage that I expected. Someone (I think it was Peter Relson) 
said that the same keywords that govern above-the-line storage also apply to 
above-the-bar. In other words, RGN should give you private storage regardless 
of location. Same goes for common storage.

Regards, Barbara

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

Re: Can System REXX run Sub=MSTR ??

[Barbara Nitz]

>Systemrexx is started automatically during IPL. What are you trying to get?

Not sure about the OP, but I would like to start it sub=mstr, too, just so it 
doesn't screw up JES2 shutdown every time. The dumb things (AXRxx) do NOT show 
up on a D A,L command (neither does AXR itself), so alternatively they SHOULD 
show up just to make it easier. Right now the first indication I get is when 
JES2 refuses to terminate. As far as I know, the xx can be just about any 
number, and short of having automation do contortions to find the correct 
number and then terminate the thing, I'm stuck. Besides, the AXRxx aren't 
always there. Seems to have something to do with health checker using system 
REXX.

Regards, Barbara

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

Re: How to un-duplex a logstream?

[Barbara Nitz]

Duplexing of a log stream is a different mechanism than duplexing a structure. 

Your CFRM policy for MACK_GENERAL  needs the keyword DUPLEX(DISABLED), which is 
the default, so you need to delete the keyword DUPLEX in the CFRM policy. 
You'll need one more structure rebuild to get the new CFRM policy active.

If you don't have a copy of the CFRM policy definitions, you need to get a 
report for the policy and rebuild the policy manually. 'Setting up a sysplex' 
SA23-1399-30 has all the keywords for the CFRM policy, including a very lengthy 
DUPLEX keyword.

Keep the duplexing for the *LOGR* policy.

Regards, Barbara

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

Re: Can System REXX run Sub=MSTR ??

[Barbara Nitz]

>Just add a "FORCE AXR,ARM" command to your shutdown automation.

That would require RACF to allow automation to issue a force command (yes, I 
know I can set it MVS.FORCEARM.STC.AXR*.* specifically). I have been at great 
pains to install a policy where Automation is not even allowed to cancel, much 
less force anything. Not that I am very successful now that I'm not responsible 
for RACF anymore.

I still think that AXR and its AXRnn should show up on a D A,L. As long as they 
run under the JES subsystem.

Regards, Barbara

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

Re: Can System REXX run Sub=MSTR ??

[Barbara Nitz]

>The AXR address space (System REXX) is started with SUB=MSTR.   REXX execs 
>that 
>that are started via AXREXX TSO=NO, run in the AXR address space.   On the 
>other hand,
>REXX execs that are started via AXREXX TSO=YES run in a AXRnn address 
>space 
>which is started under the primary subsystem. 

Harris,

that's fine if it were *my* REXX that is causing the AXRxx to get started. 
Nobody except the *IBM* Health checker is currently using System REXX in my 
installation. I have no control whatsoever over TSO=YES/NO, as I am guessing 
the TSO=YES is needed for whatever health checker wants to do. So I still 
object to AXRxx address spaces NOT showing up on a D A,L. That is making system 
shutdown unnecessarily complex and hangs up JES2 shutdown every time one of 
these things is kept around.

As for P AXR - will that take down the AXRxx's, too? This command does NOT show 
up in the 2.4 System Commands manual, much less 2.3. Since we live happily 
*without* taking down AXR, will F AXR,STOPTSO do the trick of getting rid of 
AXRxx's? *That* is documented!

Regards, Barbara

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

Re: Can System REXX run Sub=MSTR ??

[Barbara Nitz]

>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieag100/paxr.htm
>
>FORCE AXR,ARM does the same things, but in a slightly less graceful way...

Must have come in via ptf after I downloaded the manuals when z/OS 2.4 came 
out. My versions don't show it.

Just tried 
F AXR,SR STOPTSO 
AXR0214I SYSREXX STOPTSO IS ACCEPTED.  ALL SUBSEQUENT TSO=YES
REQUESTS WILL BE REJECTED

That's all I need. Will tell my automation guy to put it into the shutdown 
sequence right after health checker is taken down.
That is z/OS 2.3 at ptf level 2006. I wonder if it already worked at 1912 - 
production is still at 1912 and will get refreshed this Saturday.

Sorry to the OP for hijacking this thread, I learned something new!

Barbara

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

Re: ILR012W ALL LOCAL PAGING SPACE IS FULL OR BAD, ASM WAIT03C RSN=01

[Barbara Nitz]

>  ASSBNVSC and ASSBVSC tell you the number of slots each address space is 
>using.  You can look at those in the dump.

To make that easier, use the IPCS 'hidden' panels, specifically 2.6i (that's 
the level2 toolkit). Use SLOTCNT, it will do the math for you and you'll see 
the who gobbled up your aux. (I haven't tried it on SCM storage, so I just hope 
it works for that as well as it did for DASD AUX.)
You can (and should) use the same command for comparison with the crashed 
system. I believe this command works when set to active storage. You may be 
surprised which address spaces use *a lot* regularly.

Regards, Barbara

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

NJE via SNA/EE

[Barbara Nitz]

Between the production and AD sysplex there had historically been an NJE 
connection. Originally that was NJE/SNA. A few years ago that stopped working 
(I was told due to misconfiguration of EE), so NJE was switched to NJE/TCP. At 
the same time NJE/TCP connections were defined to the three other sysplexes we 
have. The definitions were left in the JES2 deck despite the fact that due to 
almost completely missing RACF definitions ('free for all') I had those NJE/TCP 
connections to the three other plexes terminated.

For various reasons we decided to go back to NJE/SNA via EE (don't ask). We 
tried to test-connect two of the sysplexes using SNA. It's fairly easy: Define 
a SNA line, define a logon, define the appropiate appl to both JES and VTAM, 
start everything and start the node. We failed spectacularly to get the node 
active. Despite LOGON1 showing 'inactive' and the line being active, the sn 
command always returned 'JES/VTAM interface not active' when used with the SNA 
version.
If I used SDSF node panel to start the node, it always told me 'NETSRV1 not 
active'. True, since there wasn't any JES2S001 active and should not be since 
we wanted to use NJE/SNA.

Eventually I decided to reIPL the sysprog sandplex and the AD plex *without* 
the NJE/TCP parms in the JES deck. It took 20 minutes to get NJE/SNA up and 
running (including using SN from the SDSF node panel). 

Has anyone had a similar experience? Is it described somewhere I did not find 
that you cannot start an NJE/SNA connection after years of IPLs with NJE/TCP 
keywords in the jes deck, but no actual connection started during that IPL and 
the necessary lines/sockets/netsrv having been inactive for the life of the 
IPL? Is it described somewhere that NJE/TCP takes precedence? Or have we run 
into a bug?

Regards, Barbara

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

Re: NJE via SNA/EE

[Barbara Nitz]

Thanks, Brian,

>This is almost always a problem with the VTAM definition of the NJE applid 
>that you are using.  Possibly you didn't start it or it was started before 
>VTAM or JES was ready for it to be started.
>
>The NJE/TCP connection method should work out much better than the SNA method, 
>but there is no reason why it should not have worked.

We defined and activated the VTAM NJE major node way after IPL, right around 
the time we tried to set up NJE/SNA. It was showing a status of connectable, 
and JES2 had no problem starting LOGON1 to that VTAM definition. In fact, we 
used the same commands/definitions and order of things after we had IPL'd 
without the NJE/TCP keywords in the JES2 deck.

I take it that we ran into a bug, then, if nobody is aware of it being 
documented that it shouldn't/couldn't work.

Best regards, Barbara

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

Re: NJE via SNA/EE

[Barbara Nitz]

>We ran a mixture of TCP and SNA NJE for a long, long time and then
>eventually (by accident in fact) ended up with an OSA hardware
>configuration that could no longer support SNA. We couldn't use EE
>because both ends of the connection were not MVS. So we capitulated and
>changed everything over to TCP. It's a bit less predictable than SNA
>was, but gets the job done. I see no reason to believe  that falling
>back to SNA would not work if we chose to do so (and had the necessary
>OSA hardware).

Falling back to SNA *did* work, once all the NJE/TCP parms were removed from 
the JES2 deck. It 'just' cost us an IPL on both ends of the connection. I got 
the impression that somehow the TCP parms take precedence over SNA just by 
being in the deck.

Regards, Barbara

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

Re: SYS1.MIGLIB and LNKLST

[Barbara Nitz]

>Not to hijack the thread, but... I thought ServerPac already
>automatically adds 20% (25?) free space, but I could be wrong.  In any
>case, how much free space should be allocated by ServerPac?  I saw 50%
>mentioned.  Is that enough?  Should it be the same for every data set,
>or just the three you mention?  Is it possible to get any kind of
>consensus on this topic?

I am with Carmen on this one. Per company policy I apply ptfs twice a year. 
Every time at least 3 libraries die B37 or D37, and I just hate the wasted time 
to enlarge them. All of this after I already enlarged a lot of the original 
serverpac definitions - and definitely *all* linklist data sets - by 50%, 
including directory space.
Yes, they're inactive, so easily renamed, but in addition I have to put up with 
incomplete SMS-Definitions, on reallocation SMS forces them to be SMS-managed, 
so I have to delete, reallocate with HLQ sys1, then copy, then rename the sys1 
to what it was before. Or wait at least a day to get the SMS defs done 
correctly. 
Yes, I am running with compress.

In my opinion every linklist data set should have 50% more primary (no 
secondary) space and 50% more directory space to begin with. Preferably *every* 
data set should have the 50% spare, especially given the wasted space for all 
the zFSs (think font libraries!) Or there should be a ++hold telling you to 
increase the size *before* you do the actual apply, especially for the obscure, 
seldom touched small libraries.

Barbara

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

Re: SMPE ACCEPT options

[Barbara Nitz]

>So, all you chronic backer uppers, how many times have you resorted to 
>restoring the whole shebang? Just wondering...

This year in January. Right after I made a mistake when a target dataset went 
B37 and I had to copy ist. HLQ not in ACS as non-SMS, so I got confused and 
ended up copying the wrong data set. Applied changes lost. I restored the full 
environment (DLIB vol/target vol(s)/SMPE data sets) and reran the accept, then 
the apply with the enlarged data set. All was well again.

Barbara

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

Re: IGD17272I but lots of space in storgrp

[Barbara Nitz]

One problem we had was unequal usage on the available volumes. The first 
volumes considered by SMS were almost full, no way to fulfill the primary space 
allocation. There was enough space in volumes that SMS would have checked 
later, but before SMS got there, the volcount was reached. We ended up 
increasing the volcount to the number of volumes available in the storgroup (or 
some sort of maximum), and voila, allocation went through.

Regards, Barbara

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

Re: Clarification on DASD mod conversion of SYSRES

[Barbara Nitz]

>There shouldn’t be Jake.  I'm running MOD-54's for my sysres volumes and have 
>been for years.   Probably the only issue you might have is if you are going 
>from a multi-sysres config where you had multiple system symbols for catalog 
>purposes, you'll just have to fix that to all use either ** or &SYSR1.

The last time I did this exercise (when rearranging an ADCD system) about 4-5 
years ago I fell flat on my face when I catalogued the sysres data sets on the 
sysres I IPL'd from to use the qualifier &SYSR1.. The system didn't come up 
because it found just about nothing. After staring at the manual for a while, I 
read the manual that you *must* use ** for all data sets on the sysres 
volume you use to IPL. Sure enough, once I had recatalogued everything from 
&SYSR1. to **, the system came up.

Has that changed in the meantime? Are &SYSR1. and ** interchangeable?

Regards, Barbara

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

Re: Clarification on DASD mod conversion of SYSRES

[Barbara Nitz]

>I have never has a problem using &SYSR1 anywhere ** could have been used.
>Actually, the resolution of &SYSR1 occurs very early in the IPL, long before 
>CAS is initialized.
>
>The difference is that &SYSR1 is resolved by CAS, which is not yet initialized 
>at that moment. Until then, ** does the built-in substitution.

The non-full-function CAS address space used to start way after LPA and 
Linklist are built. When I had LPA and Linklist data sets catalogued on volume 
&SYSR1. (z/OS 1.13), the IPL essentially failed, because LPA was rather empty 
and also Linklist only had the automatically added libraries in it. Very hard 
to get a system up that way.

There used to be a gap in the asid numbers (IIRC, it was a missing number 8) 
that was the non-full-function asid. When I just checked z/OS 2.3, that gap is 
gone. So either there isn't an early CAS anymore (the full-function CATALOG 
asid has number x'2B') or the early CAS uses REUSEASID=YES or the startup 
sequence was completely rewritten. 

In any case, when I check the VOLUME parm for DEFINE NONVSAM, it still reads to 
me that volume ** covers the sysres volume and &x is supposed to be 
used for *extensions* of the sysres volume. This reads:
"The symbol name is intended to represent the volume that is a logical 
extension of the system residence volume.
... IBM recommends the use of the symbol &SYSR2 for the first logical extension 
to the system reference volume, &SYSR3 for the second, and so on."

So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres 
catalogued to volume &SYSR1. instead of volume ** ???

Barbara

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

Re: Clarification on DASD mod conversion of SYSRES

[Barbara Nitz]

>What if the res volume is spreaded on two volumes ? Can we still use
>'**' ?

No, not according to how I read the book. Only the data sets on the volume that 
you specify in the IPLPARM can use **. Any other volume containing non-VSAM 
system data sets would be considered an *extension* of the sysres volume and 
would need to have the symbol(s) &SYSRn. (n>1) defined and would need to be 
catalogued to volume &SYSRn.

Barbara

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

Re: Clarification on DASD mod conversion of SYSRES

[Barbara Nitz]

>I just checked my master cat and EVERY entry has &SYSR1, 2, or 3 except
>SYS1.PARMLIB on the SYSRES It has **.&SYSR2 and &SYSR3 both are set
>to &SYSR1 since we use mod 27s.   We are at z/OS 2.3.

All, thanks for checking. 

So my conclusion way back when must have been wrong. I had left SYS1.PARMLIB 
(that came with ADCD) on the sysres. There was no SYS1.IBM.PARMLIB, and 
SYS1.PARMLIB was the one that was SMP/E-maintained. All other parmlibs were on 
the volume I had established called ZOSCAT. (One more thing that wasn't right 
with the ADCD systems).
Given that at 1.13 there was no rescue system and I had to IPL the old, 
functioning system every time I needed to make a change, I must have overlooked 
that only SYS1.PARMLIB needs to be catalogued on volume **. At least it 
didn't do any harm having everything else on sysres catalogued on ** 
instead of &sysr1.

Still, the wordings in the books could do with some clarification, preferably 
in one central place. The day I did that migration (away from the ADCD res vols 
to my own) I must have IPL'd 20 times or so until I got things right. It was a 
long day.

Barbara

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

Re: Zfs from 1 LPAR to another

[Barbara Nitz]

>For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR that 
>needed it.  Worked fine, until it didn't.  IBM's response to the PMR that I 
>opened is that the only 100% reliable way to FTP a DFDSS dump file was to 
>terse it first.  IBM does not support direct FTP of a DFDSS dump file.  So I 
>now terse every DFDSS dump file before FTPing it to other systems, and I 
>haven't had another failure in 6 years.  As I said, it will work until it 
>doesn't.

And just to add my two cents: A few years back I tried to migrate a (user) 
catalog from one RDT lpar (where I had things customized) to another RDT lpar 
(at a higher z/OS level). The dump (RC=0) got restored with RC=0, IDCAMS 
imported the catalog with RC=0, but the content was completely unusable. Trying 
to access any data set in that catalog on the DASD (that had also been 
migrated, but not via ftp) resulted in a plethora of strange rc/rsn 
combinations that really didn't make any sense. I eventually tersed the catalog 
dump and untersed/restored/imported on the other side. Now the data sets were 
accessible without any problems.
I did not open any PMR with IBM but I learned to always terse a DFDSS dump if I 
need to send it somewhere via ftp otherwise the results could get 
unpredictable. I don't think there's anything worse than a dataset that may or 
may not have been altered subtly. Don't take any chances, even if this is not 
clearly documented anywhere.

Regards, Barbara

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

Re: Zfs from 1 LPAR to another

[Barbara Nitz]

>Did you transport the catalog dump dataset with ftp? 
Yes.  I started out just adrdssu dumping the catalog, then ftp'ing. After 
restore and import the catalog was broken. Putting terse between the dump and 
ftp fixed the problem.

>If yes, this might again point to ftp.
>If not, the problem must be in the dump dataset. Then DFdss dump produces (can 
>produce) a non-standard recfm=u dataset, that will be processed correctly by 
>dfdss restore, but might confuse other programs reading it. This should be 
>documented with DFdss in my opinion.
I believe that I later checked about the difference between the untersed dump 
and the tersed dump with regard to ftp. But I had already lost enough time 
trying to get things working, so I just blamed ftp.

As for documentation - IBM does not document what doesn't work. It always 
reminds me of my IBM level2 days when I sat beside an IBM developer trying to 
figure out a problem. It turned out that the customer did something he should 
not have done, so the developer said "We don't document that you cannot wash 
dishes with a CPU!"

Barbara

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

Re: CPACF for TN3270 encryption

[Barbara Nitz]

> Do we need ICSF to be running while implementing ATTLS ?
I ran AT-TLS on a 2.1 RDT system *without* ICSF without a problem. And it was 
for more than just TN3270 traffic at TLS 1.2. I haven't tried at a higher z/OS 
level, but I don't think you need ICSF. 

Regards, Barbara

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

Re: Shopz

[Barbara Nitz]

>Has anyone been able to access shopz since yesterday?
>Has the address changed?
I can get to ShopZ at this address 
https://www.ibm.com/software/shopzseries/ShopzSeries_public.wss. 

Regards, Barbara

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

Re: Shopz

[Barbara Nitz]

>Can you actually log onto ShopZ?  I get the "welcome to ShopZ" and am able to 
>log in, but once logged in is when I get the page not found error.

This morning I was able to log in. I did not try yesterday - despite having 
ticked off 2factor authentication, I still get the stupid emails for 
confirmation. On and off, not every time I log in.

Regards, Barbara

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

Re: zOSMF

[Barbara Nitz]

>When I worked at Chase bank, We had 117 LPARS and maintenance/clone was a 30 
>minute task. So adding z/OSMF was never even brought up as a consideration.
>
>So while I understand the direction IBM is headed, its adding LOTS of layers 
>to something that sound not be hard.   Running thru screens vs submitting a 
>canned job, is hours vs minutes.

I completely agree with Terri, and I haven't even tried to use zOSMF (it is 
still not up here). I also ordered 2.5 before serverpac was dead (and then got 
delayed for a year by an ISV who could not deal with 2.5, so we had to wait).

Luckily I won't ever have to use zOSMF for installing because I'll be retired 
before 3.2 comes out (which would be the one we'd go to). If I had to, I would 
resort to CBPDO. After all, all I really need is the allocation jobs for dddefs 
and data sets (that I massage anyway each release) and then apply/accept of the 
function(s) and then apply/accept of all ptfs. For extra products I have always 
resorted to CBPDO.

As for the direction IBM is going into (dumbing down z/OS sysprogs) - who is 
going to find the problems when the next gen sysprogs don't have a clue what 
zOSMF does and what services it uses? And don't tell me IBM support will do it 
- they'll be dumbed-down next-gen, too, for the most part.

Regards, Barbara

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

Re: SMP)e

[Barbara Nitz]

>I am assuming this is for z/OS 2.4.  At my current employer, I have the PTF 
>applied.  I think that at my past employer, I ran into the same problem you 
>did.  I never was able to resolve the error at the previous employer.  
>
>The only difference between old employer and new employer, was the date of the 
>receiving of cumulative maintenance.  Previous employer, date of receiving 
>cumulative maintenance was third quarter 2021, current employer second quarter 
>of 2022.  

I have run into this a number of times for different ptfs, starting back in 
z/OS 2.3. In the easy case I had the 'required' ptf (i.e. the ptf that was 
giving me the instructions on how to do the setup) already received or received 
in the same batch.

Despite using groupextent, that ptf's hold actions never showed up in the apply 
check output. Because it was not installable, and hold actions are only shown 
for installable ptfs. I had to go back to the smppts and browse the thing 
manually to get at the install instructions. This always happened when both the 
ptf and it's prereq were received at the same time. Provided IBM had bothered 
to even provide a prereq ptf. I remember one DFHSM ptf in 2.3 that just didn't 
have install instructions. I was lucky that that ptf was already in the 2.5 
base when I got 2.5. 
I also had a case where I was unable to find out what the install instructions 
were. That ptf still hangs around in my 2.5 smppts. Since it's for a function 
we don't use, I don't much care. Until it impacts something we need due to 
coreqs.:-(

Best regards, Barbara

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

Re: SMP)e

[Barbara Nitz]

>No the problem is that you can't install these particular PTFs with everything 
>else, they have to be performed separately via an Apply the PTF by itself with 
>NO Groupextend and then Apply the
> remaining PTF's needed from the original Apply.

This is exactly what I did when I encountered this. First apply ptf A, then ptf 
B that needs whatever new path or something. The problem for me has always been 
to identify ptf A because ptf B's holddata don't show up on the apply check. 
And sometimes I just had to walk through each of the ++pre's of B to find it. 
Cumbersome is too easy a word for this process.

Regards, Barbara

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

Re: USS zlib issues

[Barbara Nitz]

Hi Robin,

>drwxr-xr-x   2 BPXROOT  RSEGROUP8192 Apr 19  2021 IBM
>-rwxr-xr-x   2 BPXROOT  RSEGROUP 1012800 Apr 19  2021 libzz.a
>-rwxr-xr-x   2 BPXROOT  RSEGROUP  405520 Apr 19  2021 libzz.so
>-rwxr-xr-x   2 BPXROOT  RSEGROUP 252 Apr 19  2021 libzz.x
>-rwxr-xr-x   2 BPXROOT  RSEGROUP  417840 Apr 19  2021 libzz64.so
>-rwxr-xr-x   2 BPXROOT  RSEGROUP 252 Apr 19  2021 libzz64.x
>-rwxr-xr-x   2 BPXROOT  RSEGROUP  413760 Apr 19  2021 libzzX.so
>-rwxr-xr-x   2 BPXROOT  RSEGROUP 252 Apr 19  2021 libzzX.x

your *.x files are definitely truncated. They all have al length of 252 which 
is extremely unlikely. This is what it looks like on my system (only the *x 
files):

libzz.x fff--- --s-  BPXROOT  SYS1 6723
libzzX.xfff--- --s-  BPXROOT  SYS1 6723
libzz64.x   fff--- --s-  BPXROOT  SYS1 7209

The last change date on mine is 2023/01/06, which is the time I last put 
maintenance in. No idea what that was, but I guess that's your only chance of 
fixing the truncated stuff. The date you show is when this stuff was first 
installed by IBM. I am guessing for the ServerPac.

Regards,  Barbara

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

SMPE UPGRADE Command

[Barbara Nitz]

I am attempting to install zSecure. I get 

GIM58901E ** APPLY PROCESSING FAILED FOR SYSMOD HCKR240. SYSMOD HCKR240 WOULD 
 HAVE CAUSED A CHANGE TO THE MVST ZONE THAT CAN NOT BE PROCESSED  
 COMPLETELY BY PRIOR LEVELS OF SMP/E. USE THE UPGRADE COMMAND TO  
 ALLOW SMP/E TO MAKE SUCH CHANGES.

I read about the upgrade command and still don't know if I can safely use it. 
My SMPE is at 36.105, presumably to get upgraded by the latest refresh which is 
installed but not yet activated (I wanted to do that together with z/Secure).

So if I run the UPGRADE command on my target (and probably later on my DLIB 
zone), can I then still use my current level of SMPE on those zones? There 
won't be any level  lower than 36.105.

And another question: I am at z/OS 2.3. Am I supposed to install z/Secure V240 
over RACF 2.3? (We got the product download links from IBM, so I didn't have 
any choice but to use V24.) Documentation is abysmal.

Thanks in advance, Barbara

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

Re: SMPE UPGRADE Command

[Barbara Nitz]

>Have done a number of CBPDO installation sunder z/OS 2.2 last year that all 
>required using the UPGRADE command. If you are using a new SMPE environment  
>then go with the UPGRADE. Had no issues doing this.  But it is confusing as it 
>implies that the zones you create with the version of SMPE you have are down 
>level to the version of SMPE you have!!!

Not only that, but one places states that UPGLEVEL indicates the highest 
SMPE-version one can use against that zone. At least that is how I read it, so 
I am more confused than ever. And since Kurt Q. hasn't chimed in...

Unfortunately the zone I would have to use UPGRADE against is my z/OS zone. I 
don't really understand what the UPGRADE command does (other than it *creates* 
an UPGLEVEL subentry in the zone definition - there aren't any right now, and 
it has something to do with how modules are kept in the SMPLTS) or why it is 
necessary to use it at all. So I will remove the dddefs for z/Secure from my 
z/OS target and DLIB zones and create separate zones for z/Secure, to be on the 
safe side. 

I am still not really convinced that I should install z/Secure 2.4 when z/OS is 
at 2.3.

Thanks to all who responded,
Barbara

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

Re: SMPE UPGRADE Command

[Barbara Nitz]

>If you plan to continue to use SMP/E 36.105 or higher when processing
>the subject target and dlib zone, then it is perfectly safe to use the
>UPGRADE command.

Thanks Kurt, for confirming that it should not be a problem. In the meantime I 
found out that IBM had ordered V24 for us *without* asking for our z/OS level, 
which is 2.3, all on the strength of us having bought V2. This might explain 
the discrepancy with the SMPE level. I am now waiting for the software version 
that fits our z/OS version and see what happens with the apply.

The biggest problem is that there is no good documentation coming with the 
CBPDO. I seem to remember that the program directory contained the software 
prerequisites, i.e. the z/OS level fitting the product. Was unable to find 
that, though. 

>Chuck Norris never uses CHECK when he applies PTFs.
Is he a z/OS champion?!? :-)

Barbara

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

Re: IBM AOAR O44855

[Barbara Nitz]

>Is anyone using this feature 
>https://www-01.ibm.com/support/docview.wss?uid=isg1OA44855

I implemented TSO PrePrompt when I was RACF Admin. If someone is attempting to 
hack into the mainframe using userid/password, I didn't want them to know if 
their userid was wrong or their password. 
After x invalid combinations (x is whatever your amount of allowed invalid 
passwords is before revoking you) the userid gets revoked, as before.

It threw off the session manager we used to use back then, and it threw off a 
screenscraper that the compliance department uses (screenscraper=shudder). Both 
got around it.

Barbara

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

Re: Sysplex Maintenance and USS

[Barbara Nitz]

>So, how does one rollout maintenance in a sysplex one system at a time without 
>disrupting the ability to access these products?

The way I do it for the links that weren't totally screwed up when I started 
here:
at /usr/lpp I mount a 'links'-ZFS, i.e. /usr/lpp/java gets an 
OMVS.&SYSR2.JAVA.LINKS ZFS mounted. The actual Java-versions are then mounted 
'inside' that LINKS-ZFS. For version changes of Java all I need to do is 
unmount the old one, set a new mount point for the new version and off I go. 
For refresh of an existing Java version, I put in a new &SYSR2 LINKS ZFS since 
I normally refresh Java together with z/OS when &SYSR2 changes anyway. Any 
other ZFS name (different from the old one) would do it, too, but then I need 
to remember to update BPXPRMxx.

So the 'trick' is not to mount to usr/lpp directly but instead mount another 
ZFS at the appropriate usr/lpp mount point and mount the product off from there.

Regards, Barbara

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

Re: SMPE BYPASS(HOLDSYS,HOLDERR)

[Barbara Nitz]

I remember when I installed this that I had a lot of trouble with the ptf(s). 
That was due to the fact that one of the IGG modules that had to get restored 
had a usermod (for CA-DISK) on it. I don't remember if that module was even 
touched by the ptf. Restoring that usermod was a nightmare - SMPE eventually 
told me that it could not figure out any relationships for restore anymore and 
I should do it myself. I ended up accepting a just installed new PTF that fixed 
some PE. After that, SMP/E was able to do the restore check with CC=0. Out came 
about 200 ptfs. I applied the crypto stuff, then reapplied all the rest of the 
ptfs. And the usermod. (And I had done accept before I started that refresh.)

While it was nice to have the functionality rolled down to 2.1, the complexity 
was staggering and I didn't like having it forced upon me in the service 
stream. I was tempted to just leave the crypto ptf(s) out and wait for 2.3 
which would have it in the base.

I just reiterate what everybody else already told you: Backup your complete 
SMP/E environment including the target and DLIBs before you do any apply of 
that ptf. And then do real thorough testing of just about everything DFSMS. The 
crypto function is pretty pervasive (as it should be).

Barbara Nitz

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

Re: 64-bit application dump analysis [was: RE: Problems with ESTAEX invoked in AMODE 64 . . . ]

[Barbara Nitz]

> SYSMDUMPs can be written to SYSOUT, and then, for the ones you want
>to look at with IPCS, extracted to a sequential data set.  pool.  You can 
>use
>a spool file management program (for example,  SDSF or EJES) to do the 
>extraction. 

While that is true, I do not recommend doing that. Most z/OS installations have 
ISV products that read complete jobs from JES2 spool and archive them somewhere 
else. The products I know only look at the number of lines in the job for their 
decision to get it from spool. They totally disregard how *long* these lines 
are. A sysmdump in JES spool doesn't have all that many lines, but those lines 
are not 132 byte long. They are 4160 byte long.

We got badly bitten by a thoughtless sysmdump dd sysout=* in a (USS) 
application that kept abending with a sysmdump every time a new address space 
got started (and that was several per minute!) It lead to a 'spool shortage' in 
our archival product followed by a severe JES2 spool shortage. I had a hell of 
a time figuring out why the archival product was in a spool shortage and did 
not reject the extremely large jobs (byte-wise) in the first place.

As a consequence, I removed all sysmdump dd sysout=* cards in all STCs. I told 
the owners of those STCs that they would have to allocate sysmdump data sets 
for their STCs and figure out how to save the one they had gotten before STC 
restart overwrote it.

Admittedly the setup we had was dumb. The STC sysmdumps should never have gone 
to sysout=*, they should have gone to a class that won't get archived. I know 
that my current installation has a similarly dumb setup, this time for batch 
jobs. They all write those 3700 page sysudumps and in addition the ceedumps to 
sysout=* and have it archived for however long the jobs is required to be 
archived. Even with linesize 132 that is a lot of DASD and later tape space. 
Never mind that there is usually a TDUMP accompanying the ceedump. In my 
current installation I appear to be the only one who can read a SYSMDUMP using 
IPCS, and I had exactly one person ask me how I did it and if he can use IPCS, 
too. 

Regards, Barbara

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

Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!

[Barbara Nitz]

You say that the problem happens when all the tasks terminate. Your problem is 
with not enough LQSA for termination. During termination a number of RBs are 
getmained by RTM to handle termination - like an RB that your ESTAE gets 
control under (a PRB, IIRC). Or a PURGEDQ SVRB. Depending on what your ESTAE 
does, you'll need more LSQA for further stuff. 

I don't have a rule of thumb how much LSQA is needed per TCB. Given that you 
say you create 1000 tcbs, and each tcb creates at least one subtask, we're 
talking at least 2000 TCBs. Plus their associated RBs and CDEs. I'd guess that 
you need at least 6MB below the line of storage reserved for LSQA, possibly 
more. The only way to do that is to write a custom IEFUSI that really reserves 
that much LSQA especially for your job. Or the equivalent parmlib member.

Remember that LSQA 'grows' from top of region below downwards while private 
storage 'grows' from bottom of region upwards. So conditional getmains don't 
help here IMHO. You would have to determine current top of region 
programmatically and then subtract 1-2MB for termination and then check if 
you've still got enough room to do your getmain.

Anecdote: Before IBM introduced command classes and all the messages that go 
with too many commands issued at the same time there used to be regular wait 
states (wait07E, IIRC) due to LSQA exhausted in *master*. Commands execute in 
*master* (for the most part). Too many commands at the same time generated the 
exact same situation you currently have - not enough LSQA left. Which is really 
deadly when it happens in asid 1. IBM only allows 100 commands per class these 
days. If more are issued, they get held back until there's 'room' again to have 
them execute.

Why do you need 1000 tcbs?

Regards, Barbara

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

Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!

[Barbara Nitz]

>We had a similar issue in IMS regions, stalling after out of memory abend, no 
>way to get rid of them, IMS STO REG, z/OS CANCEL and z/OS FORCE did not work, 
>except with some vendor tool cancel that just gets rid of the address space 
>without proper cleanup that gets you closer to IPL.I wondered back then, how 
>dare the z/OS RTM routine doing getmains or module loads in a region that 
>abended with end of memory, does not make sense to me.The answer is probably, 
>it has been that way ever since and use IEFUSI.Why would terminating an 
>address space in 64bit or 31bit mode require loading 24bit routines, sounds 
>awkward?!

The address space *task structures*  (TCBs, PRBs, SVRBs, IRBs, CDEs) are all 
allocated in below the line LSQA. It has been that way since before MVS/XA, I 
think. The RTM2WA is allocated above the line. Also, there is no one 'RTM 
routine' that gets executed. When RTM gets control (remember PSW swap?) it 
doesn't *know* yet what it got control for. So it just needs to figure that 
out, which costs some storage. And recovery always goes back to the last PRB, 
which means that RTM gets control under a new PRB to ensure that things are not 
muddied by the recovery (think dump analysis). And then system integrity 
demands that proper cleanup is done (as in resource managers need to run), not 
to mention possible recovery routines that the application set up. Or the 
routine doing the cleanup. Terminating an address space without violating 
system integrity or hanging up the address space (or the system) is a very 
complex business.

In a previous life I also had to deal regularly with IMS regions not 
terminating due to various reasons. In 50% of the cases the 'callrtm' program 
(which has now morphed into a variant of the force command) did the trick. In 
all other cases IMS needed to get recycled. I always took a dump to determine 
the TCB address that I needed to terminate (the bottom one that needs to 
terminate so everything above can terminate), and most of the time a few of 
those ominous 'non-cancelable' bits were on. What is worth more? System 
integrity or IMS restart?

As for routines running in 24 bit - if it is an application routine, it 
*should* be at least located above the line. But some of the *system* routines 
*must* run in 24bit, IIRC. IBM has made a real effort over the years to put as 
much as possible above the line, without rewriting all of the operating system. 
And yes, IEFUSI is there to deal with reserving sufficient LSQA to be able to 
terminate cleanly.

Barbara

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

Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!

[Barbara Nitz]

On Thu, 30 Apr 2020 09:09:32 -0400, Peter Relson  wrote:

>
>z/OS FORCE did not work
>
>
>Wanna bet?
>
>FORCE,ARM runs in the address space so would have been affected.
>FORCE does not.

Doesn't matter. With an IMS region, you cannot use cancel (z/OS: 
"non-cancelable, use force arm"). You cannot use force arm (z/OS: "cancel 
first, please"). And you cannot use force because IMS intercepts that and tells 
you to terminate the IMS region by de-registering it from IMS. Which doesn't 
work because it is already *unknown* (i.e. deregistered) in the control region, 
but the de-registering hasn't made it down the tcbs in that IMS message region. 
Sometimes the callrtm program worked after the 5th invocation, but sometimes it 
didn't work even after 10 invocations.  (With the dumps to verify it didn't 
work in between invocations.)

IMS message regions are BAD, IMHO.

Regards, Barbara

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

Re: RED Alert Today Regarding z/OS Service Orders

[Barbara Nitz]

>Anyone else having trouble downloading this zip file?
>
>ftp://public.dhe.ibm.com/eserver/zseries/zos/alert/PTFList.zip

Hi Bob,

another ftp-Link from IBM. My company hat decided that ftp is globally 
forbidden, but someone else escalated for different reasons. Now ftp is open 
again at the proxy level. BUT: I was told that the newer browsers (like 
company-mandated Edge) don't support Edge anymore, either. We luckily still 
have IE, and using that allowed me to download the link.

In other words: Check your firewalls, proxies, browser level.

Best regards, Barbara

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

FTP-Links in IBM Websites and PTFs

[Barbara Nitz]

>We have ftp blocked at the corporate level.  Has anyone found an HTTPS link to 
>download this file?  I used 'Contact IBM' at the bottom to inquire but not 
>optimistic. 

You're not the only one. Now that the 'modern browsers' don't support ftp in 
websites anymore, I wonder if IBM will wake up and change their practise of 
providing ftp-links. At some point in the not-too-distant future IE will not be 
available anymore in a corporation, and then there won't be any way to get at 
(sometimes vital) information:

- Holddata are ftp-Links only. And I want to download holddata without ordering 
anything via ShopZ. Not to mention that it will be cheaper for IBM in the 
longer run to provide these data another way.
- The ++HOLD's in ptfs often only contain ftp-Links for any documentation. I 
shudder to think what happens if I can't use ftp anymore and the doc says that 
some default was changed, only I cannot read the doc. 2 Alternatives: Hope for 
the best or open an SR for each ptf to have IBM support send me the doc. Again 
expensive for IBM.
- (Updated) PDFs like recently for the 2.4 docs. Again an ftp-Link, and if I 
cannot get at it, then I either have to manually download each and every book 
in the collection via http(s) in the browser or use old docs. Pity when I 
didn't install ptfs with documentation as ftp-Link only until the books are 
updated and I can see what the ptf does. In this case, it would be very 
time-consuming for each customer to get offline docs.

I'm sure there are other cases where IBM only provides docu via ftp-Link. Or 
equally as bad - as a link into some public 'data room' (The one with 'box' in 
the name comes to mind) which is also forbidden at the corporate level here.

My colleagues tell me that the same is true for CA and BMC (or whatever they're 
named today).

IBM, when will you wake up?

Barbara

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

Re: FTP-Links in IBM Websites and PTFs

[Barbara Nitz]

>> - Holddata are ftp-Links only. And I want to download holddata without 
>> ordering anything via ShopZ.
>Not true.  You want the IBM HOLDDATA without using FTP?  Use SMP/E
>RECEIVE ORDER and indicate downloadmethod="https".

We have never used that here, so I'll check into it when IE goes away. We do 
use https for downloading from ShopZ.

What about ftp links in ptfs? One of several examples from my last refresh in 
January is OA58114 (the DPfD ptf). The 114 page pdf documentation is an ftp 
link inside the ++HOLD. ftp traffic other than through a browser is blocked at 
the firewalls, so while I am familiar with the ftp CLI I cannot use that, 
either. I was sorely disappointed when I could eventually download the docs 
only to find out that DPfD only works on a z15.

Regarding Quickref: We do use Quickref, but it doesn't help me at all when it 
is brandnew information placed in a ptf (see above). Personally I prefer my 
documentation offline on my private drive.

The Red Alert thing that went out was originally also an ftp-Link only. The 
consolidated books mentioned here last week were ftp-Links only (never mind 
that the inhouse-scan of the zip took longer than the timeout for the website, 
so I couldn't get at that, either!).

I repeat my question: When is IBM going to wake up *everywhere* that ftp-Links 
become inaccessible now that the browsers don't support them anymore? Just this 
morning we were told that Chrome goes away corporately. Firefox is not allowed, 
so we're stuck with Edge. Which doesn't do ftp anymore.

Barbara

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

Re: Print a SYSMDUMP

[Barbara Nitz]

>I consider //SYSMDUMP DD SYSOUT=* to be the best way to manage batch job
>dumps. We've done this for years with excellent results.

Until you get burned really badly in a commercial installation: We had an 
address space (STC) where the job output went into the archive product. Someone 
had put sysmdump dd sysout=* in the JCL. That STC had its roots in OMVS and 
kept abending and terminating, writing a dump each time. The parent process 
kept restarting the address space.  
We got the messages that the spool of the archive product was full which in 
turn kept the job output including the dumps in JES2 spool. We weren't fast 
enough deleting the job output in JES2 spool. 
The archive product counted lines only, regardless of lrecl. Each sysmdump line 
was 4160 byte long, which wasn't readily recognizable und substantially longer 
than a 'regular' output line. It took a long time to determine what had filled 
the archive product's spool because the (long) lines weren't that many, the 
byte count was. And the byte count wasn't shown easily.
As a result, sysmdumps (other than to a data set) were banned from JCL.

>What is the 21st-Century rationale for not allowing everyone to use IPCS?
Mostly ignorance, I would guess. We have allowed application programmers to use 
IPCS (I think), because I seem(ed) to be the only one capable of reading a 
transction dump and got tired of giving them the traceback. Despite that, I am 
not sure that anyone other than myself (in our installation) knows how to use 
IPCS. It is not just a question of knowing which command to use to produce 
results, it is a question of interpreting the command output. That knowledge 
seems to disappear at a fast rate. And products like z/OSMF dumb down the 
sysprogs even more.  I am guessing that in 10 years nobody outside a z/OS 
software producing company will know how to use IPCS anymore.

Barbara

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

Re: Print a SYSMDUMP

[Barbara Nitz]

>And if I remember correctly you can look at ACTIVE control blocks/memory
>using IPCS.

Yes, you can. No problem for common storage because that is visible to every 
address space. active can also be used to peek into other address spaces and 
their data spaces. I hope everybody has protected that function! Here my group 
is the only one that can use it and I am the only one who knows how :-)

Barbara

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

Re: New to DFSMS? New to DFSMShsm? Education! [EXTERNAL]

[Barbara Nitz]

>There are a few sites that seem to hit firewall issues, and IBM BOX is one of 
>them.  
>
>These links are set up so that anyone with the link can access the files in 
>the box folder, but IBM can't do anything about your firewalls.  
>
>The work around is to access these files from a personal, or non-firewalled, 
>computer.

Which is usually forbidden in those sites that firewall box.com. Why does IBM 
insist on putting documentation where customers can get at it? Box.com is one 
example (some ptf hold actions are on box.com, for IBM's convenience, no 
doubt), using ftp-Links to provide documentation (hold data, ptf hold actions 
and otherwise) is another example, when ftp is not supported by the corporate 
browser. Only https and sometimes ftps are.

Each and every site that gets their firewall no-no list from outside (in 
Germany that are most if not all of the big banks that have to adhere to 
regulatory 'counsil') will block box.com. And it is just about impossible (not 
to mention forbidden) to use private computers to get at data and then bring 
those data into the company. All corporate laptops are blocking USB ports, and 
email doesn't allow large attachments. So please DON'T consider private devices 
a 'bypass'!

Such a shame in this case, as it would be nice to see that for my trainee. 
Almost criminal for cases where I cannot get at the ptf documentation to see if 
new parms came in that will prohibit me from IPLing successfully!

Barbara

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

Re: Serverpac installs January 2022 and beyond - Requests

[Barbara Nitz]

>You can't change the size of a dataset and you can't change PDS to PDSE. It's 
>easy in ServerPac to mass change to PDSE. It skips ones that aren't eligible.

You can't? As far as I am concerned that is a definite roadblock. IBM never 
sizes the data sets in such a way that they won't go x37 at the first apply. I 
routinely at least double allocations for things like linklib and miglib and 
essentially all linklist datasets because they don't have extents and are more 
prone to x37. 

It's a good thing we have always planned to order 2.5 as soon as it becomes 
available, so I get to use serverpac for my last ever z/OS install. The one in 
four years will have to be done by my successor because I'll be almost retired 
by then. 

Never mind that we haven't set up z/OSMF, either. Once we migrate to the z15, 
we can take advantage of system 'recovery' boost so z/OSMF can come up on the 
teeny tiny sysprog lpars. 

Regards, Barbara

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

Re: Serverpac installs January 2022 and beyond - Requests

[Barbara Nitz]

Hi Marna,

>Making everything bigger is not a good option.  Not everything "needs" to be 
>bigger, but there are those that even 40% won't be enough.I think 
>creating z/OSMF product delivery without the ability to change the size and 
>location of the datasets (easily) is a bad idea. 

I am with Brian on the subject of sizing. I would allocate lnklst (target) 
datasets without extents at 200% of what is used right now. And increase 
directory sizes accordingly. And remember to increase sizes for the 
corresponding DLIB data sets. But that won't help the x37 completely (and I 
don't think that there is definite help for it). If it helps, I can compile a 
list of which data sets blew up with x37 over the course of installing 2.3 and 
8 refreshs (we do a refresh twice a year). IIRC, the datasets where new 
functions went in blew up.

I don't much care how converting PDS to PDSE is handled, but I also think that 
z/OSMF absolutely *MUST* provide the ability to edit the jobs before they are 
submitted.

>I am wondering, if it might be of better use to have the capability of 
>accommodating the need for more space in a more ongoing manner?  
What would help in my opinion would be a pre-apply hold action for each dataset 
that might blow up because a lot got changed. Then it is my responsibility to 
increase the size before apply. Or z/OSMF can take a look and automatically 
reallocate the target and DLIB data set, copy the old stuff in and then use the 
new stuff for the actual apply.

Of course, that assumes that apply is always done into inactive target data 
sets. Mine are not even catalogued. Apply of a large set of ptfs into the 
active system is a bad idea anyway, in my opinion.
My idea probably also runs counter to the way the full system replacement is 
set up, both in the dialogs and in z/OSMF, because they use the data sets the 
install went into for IPL.

Regards, Barbara

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

Re: Serverpac installs January 2022 and beyond - Requests

[Barbara Nitz]

>Its interesting, because I don’t have any products that give me extra extents 
>except what SMS does for me space wise, and I have never increased my dataset 
>size allocations.

Just as a preparation for increasing allocations, here is what failed x37 in 
the past 8 refreshes (all on the *installation* target volume, never IPL'd 
from). I apply maintenance twice a year, too, and it is always upwards of 
1000ptfs. SMPE was dealing with a few of those x37 doing in-flight compresses, 
but I had only the last refresh without having to increase sizes.
#1
IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB 

IEC031I D37-04,IFG0554P,,APPLY,NUCLEUS,SYS1.NUCLEUS 

IEC031I D37-04,IFG0554P,,APPLY,SASMMOD1,ASM.SASMMOD1
 
IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0
 
IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0
 
IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0
 
IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0
 
IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0
 
IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0
 
IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0
 
IEC031I D37-04,IFG0554P,,APPLY,SCEERUN,CEE.SCEERUN  
   
#2
IEC032I E37-04,IFG0554P,,APPLY,SGIMTENU,GIM.SGIMTENU
 
IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG 
   
IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG 
   
IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD

IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG 
   
IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG 
   
IOEZ00312I Dynamic growth of aggregate x.SIZUUSRD in progress
#3
Made an error during increase of data sets, ended up restoring everything and 
increasing (joblogs from before restore not saved)
SCBDMENU  
SMPSTS 16->50 trks, sec 5 
SASMMOD1 50->80 trks   
#4
Accept of previous maintenance:
IEC032I E37-04,IFG0554P,,ACCEPT,ABBLLIB,BBL.ABBLLIB 
 
Apply new:
IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB 

IEC031I D37-04,IFG0554P,,APPLY,SICELINK,SYS1.SICELINK   
 
#5
Accept of previous maintenance:
IEC032I E37-04,IFG0554P,,ACCEPT,AGIMTENU,GIM.AGIMTENU   
   
IEC032I E37-04,IFG0554P,,ACCEPT,AERBPWSV,SYS1.AERBPWSV  
   
IEC032I E37-04,IFG0554P,,ACCEPT,AHAPINC3,HAP.AHAPINC3   
IEC032I E37-04,IFG0554P,,ACCEPT,AGIMTENU,GIM.AGIMTENU   
  
Apply new:
IEC032I E37-04,IFG0554P,,APPLY,SERBPWSV,SYS1.SERBPWSV   
 
IEC032I E37-04,IFG0554P,,APPLY,SEEQINST,SYS1.SEEQINST   
 
IEC031I D37-04,IFG0554P,,APPLY,MIGLIB,SYS1.MIGLIB   
   
IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0
 
IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD
 
IEC031I D37-04,IFG0554P,,APPLY,SCEERUN,CEE.SCEERUN  
   
#6
IEC031I D37-04,IFG0554P,,APPLY,SERBLINK,SYS1.SERBLINK   
 
IEC031I D37-04,IFG0554P,,APPLY,CMDLIB,SYS1.CMDLIB   
   
IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB 

IEC031I D37-04,IFG0554P,,APPLY,NUCLEUS,SYS1.NUCLEUS 

IEC031I D37-04,IFG0554P,,APPLY,SASMMOD1,ASM.SASMMOD1
 
#7
IEC032I E37-04,IFG0554P,,APPLY,SISFTLIB,ISF.SISFTLIB
   
IEC032I E37-04,IFG0554P,,APPLY,SERBPWSV,SYS1.SERBPWSV   
   
IOEZ00312I Dynamic growth of aggregate x.SAZFAMOD in progress
IEC031I D37-04,IFG0554P,,APPLY,SERBLINK,SYS1.SERBLINK   
   
IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD
   
IEC032I E37-04,IFG0554P,,APPLY,SCEELPA,CEE.SCEELPA  
   
#8
Accept of previous maintenance:
IEC032I E37-04,IFG0554P,1,ACCEPT,AGIMTENU,GIM.AGIMTENU  
  
IEC032I E37-04,IFG0554P,1,ACCEPT,AISFTLIB,ISF.AISFTLIB  
  
IEC032I E37-04,IFG0554P

Re: HELP!! IPL failure

[Barbara Nitz]

>A D XCF command isn't showing the system active.The ISGLOCK#SYSA connector is 
>showing active to structure ISGLOCK

From the other system, try forcing the connection of ISGLOCK#SYSA to the CF. 
Take a dump from the other system of the XCF address space that also includes 
the ISGLOCK structure when SYSA is fenced. Doesn't matter which system you use. 
This sounds like a serious bug and you should have documentation.

Try to rebuild everything out of the CF that houses ISGLOCK to the other CF 
that you hopefully have. Then check the connection again, it should be gone.

All else failing, reset the CF lpar (power off/power on that LPAR). That will 
cost you all systems in the plex (assuming there're more than 2) and you will 
need to IPL the complete sysplex. And use a freshly formatted primary CFRM 
dataset to be on the safe side. Start that using the CFRM parm in couplexx.

HTH, Barbara

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

Re: Serverpac installs January 2022 and beyond - Issues

[Barbara Nitz]

Terri,

I had found the migration workflow here (of all places as a link for the 
upgrade to the z15 that we just completed): 
https://www.ibm.com/docs/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.e0zm100/Export_zOS_V2R3_to_V2R5_Upgrade_Workflow.html
I wasn't too happy with it because it doesn't work offline, you have to read it 
online and don't really have a chance to edit or mark anything as complete or 
irrelevant for your installation.
Now Marna tells us the ptfs where it can be found. That little tidbit of 
information hadn't made it to my corner of the world. We do have oa60711 
installed, but when I check the path /usr/lpp/bcp/upgrade, that is not a 
readable format. It can probably only be read using zOSMF so it is useless to 
someone without zOSMF up and running who uses the serverpac.

As for a zOSMF install - I had always planned to use the serverpac for 2.5. We 
haven't set up zOSMF yet (that will have to happen after 2.5 is up and 
running). Like Dave, all I really need from the serverpac are ALLOCDS and 
RESTORE. I don't even run the full UP and I create my own catalog job. From 
painful experience, I also compare everything to everything to make sure all is 
complete (SMPE zones against the restored volumes, target volume against the 
catalog).

As I had mentioned before on ibmmain, I do a lot of allocations quite different 
from what IBM delivers so it is imperative that I can see the JCL before 
submitting. I had heard that I cannot see it and had planned to put a JCL error 
into the jobcard so that I can change from there. Doing that would probably 
play havoc with what zOSMF *assumes* and enforces.

I have one set of installation volumes (TGT125, ZFS225 and DLBV25) specific to 
the release. TGT125 will NEVER get IPL'd, I clone from there to everywhere. All 
'extranous' data sets (CPAC, the SMP environment) goes SMS and stays on my 
sandbox. I also don't IPL the CPAC system that comes with the serverpac. 
Everything on DLBv25 and TGT125 is uncataloged. Only the ZFSs are cataloged 
under the HLQ INST25. They, too, get cloned to the actual sysres and renamed 
during cloning.

After reading your posts, I am really glad I used the serverpac, especially 
with zOSMF insisting that everything is done exactly as zOSMF defines as 'the 
right way'. It sounds like a nightmare to me to keep my working process using 
z/OSMF. I'll leave that to my successor, as 2.5 is my last operating system 
install.

Barbara

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

Re: Serverpac installs January 2022 and beyond - Issues

[Barbara Nitz]

Hi Marna,

thanks for your reply.

>Interesting you just happened upon finding the z/OS upgrade material on the 
>z/OS website :).  I think we need to make it easier to find, as perhaps the 
>System Level portion of the z/OS release bookshelf isn't the best place?  
I was expecting it where the usual books / pdfs are. As far as I am concerned 
it should be where the InfoRoadmap, the ReleaseGuide and the 
UpgradeReferenceSummary are.

We don't have z/OSMF up and running yet, so getting it out of the ZFS file 
system was not an option. I just remembered that you have said that IBM will 
export the complete workflow und put it somewhere (it was github back then, I 
think).

>The other format is an export that IBM did ourselves, and put on the IBM 
>Documentation site. I think this is the one that you encountered.  It is all 
>the material that is found in the z/OSMF Upgrade Workflow, just available with 
>the rest of the z/OS books so you could reference it outside of z/OSMF.  Since 
>it hasn't been tailored to your system, and all the steps are listed, whether 
>or not they are irrelevant to you, you'll find it rather long and probably not 
>as helpful as if you would have created your own customized file, or even done 
>it from with z/OSMF itself.  I agree, it's not the best, which is why it isn't 
>the preferred option. 

Yes, this is the one I had looked for and found. I have no problem reading all 
of the actions (that's what I did with the migration book, anyway, and it 
sometimes lead to interesting discoveries especially in a new installation when 
I wasn't sure yet what gets used. Often the oldtimers in that installation 
didn't know either that things were obsolete by now). 

I did a 'save as' in the browser and saved the html pages to my laptop. I 
expected the content to be on my laptop, but it wasn't. When I opened the html 
pages using notepad, there was some small crap in it that was way too small to 
be the information I had seen online. I actually had to go back and search for 
the link again, save that to my bookmarks and  read online. When I skipped a 
few chapters, it took forever to load the intended content. It felt like that 
content had a lot of external links in it that would explain why it was so slow.
Had I had the content on my laptop, I would have done some editing and only 
kept what was relevant to me. 

Best regards, Barbara

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

Re: Serverpac installs January 2022 and beyond - Issues

[Barbara Nitz]

Hi Kurt,

>Does z/OSMF have a different look and feel than CustomPac ServerPac?  Yes. 
> However, z/OSMF can certainly install as you've described here: you can 
>specify your three installation volumes for the target and distribution 
>libraries, you can let SMS manage the CPAC and SMP/E data sets, your 
>targets and dlibs can be uncataloged, the zFSs can be cataloged with HLQ 
>INST25.  And you don't have to IPL the installed system.
>
>If anyone is confused how to tell z/OSMF about your unique installation 
>desires, let me know.  I bet in most cases, like those described above, 
>there's a way to make it happen.  I'm here to help.

Thanks for your offer to help!

Not having seen the zOSMF method, I still think that the actual process of 
installing is or should be similar. I know serverpac full system replacement 
needs a usercat (that would become the master cat if you wanted to replace that 
and IPL the new system) for allocating and restoring the 'collisions' (all 
allocated data sets in lnklst and the logon proc). Both zOSMF and serverpac go 
and set the SSA into that usercat, I think. What I don't understand is why my 
2.5 serverpac wants to cement the SSA in the DDDefs. I deleted all of that 
before running the UP job. But then with serverpac, I get to see the jobs 
before submitting them. zOSMF might do it the same way and I think that is 
where Terri has the problem with the aliases she keeps mentioning.
And I didn't understand why the SSA should get cemented in the dddefs, anyway.

What I found really annoying in my serverpac was that I was asked for the 
jobclass for sysout data sets, dutifully specified an asterisk (take the one 
from the jobcard) and then got generated statements like this: SYSPRINT DD *. 
It took me a while to understand why I had gotten either abend001 or abend04c 
and had no sysprint to look for the reason.

Best regards, Barbara

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

Re: Serverpac installs January 2022 and beyond - Issues

[Barbara Nitz]

>> What I found really annoying in my serverpac was that I was asked 
>> for the jobclass for sysout data sets, dutifully specified an 
>> asterisk (take the one from the jobcard) and then got generated 
>> statements like this: SYSPRINT DD *. It took me a while to 
>> understand why I had gotten either abend001 or abend04c and had no 
>> sysprint to look for the reason.
>
>I'm confused.  ServerPac is available now in two forms; the old-school 
>CustomPac Installation Dialog, or z/OSMF portable software instance.  Is 
>this a comment on the workflows supplied with the z/OSMF portable software 
>instance, or with the CustomPac Installation Dialog?
The SYSPRINT DD * (and other output to spool)  was generated using the 
old-school serverpac/custompac. We don't have zOSMF up and running, so this was 
strictly generated from the CPP ISPF panels. Even some JCL in the CPAC proclib 
was generated this (wrong) way.

In any case, I am now done with the dialogs, and comparing /etc and /var with 
our actual etc and var.

Regards, Barbara

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

Re: Serverpac installs January 2022 and beyond - Issues

[Barbara Nitz]

>Those files are not stored in EBCDIC. I used ISPF 3.17 to View the files using 
>the UTF-8 option. Then you can see the XML source.

Thanks for that pointer. I did use the command "ASCII" (which got command not 
found), but "ASCII" is an IPCS command. :-( 

Regards, Barbara

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

AW: Serverpac installs January 2022 and beyond - Issues

[Barbara Nitz]

Good morning Marna,

thanks for reporting that, someone else may have a need for the full html. I 
don't have much to do as far as migration actions go - SDSF was done a long 
time ago. I still need to do comparisons for /etc and /var, and set up ieasys 
to pick the parmlib members for 2.5, and then I am good for the first IPL.

While I do have a 'successor', it is an early thirtiesh  woman full of 'yeah, I 
can do that' but she doesn't deliver anything after a year of being in the 
department and getting 'mentored' by me. She doesn't read up on any 
explanations and doesn't look up information for the task she was set. The only 
thing she ever did was set up our 'ipl sheet' in excel (which I don't do), and 
even that was sloppy and I had to correct a lot. So I am not hopeful that she 
will be able to do any customization for z/OSMF, much less do the conceptual 
work required. I will probably be the one to do that. :-( She was absent the 
full time I did the 2.5 install, and that is what she is supposed to do the 
next time. While my boss tells me that I 'expect too much', a few of my 
colleagues have the same opinion as I do.

Is it still totally important to set up everything for z/OSMF *exactly* as IBM 
decrees? The first hurdle is already that we cannot use the uid/gid IBM uses 
because that is already taken. Our (auto)UID/GIDs are in the upper range 
counting down. Which means to go over the ZFSs and change ownership throughout, 
right?

And how are you? Here Covid numbers are on the rise again, not enough people 
are vaccinated (most especially not children under 12) and we won't have 
another lockdown, according to the just elected government. I am still in my 
home office and enjoy my dog who now starts to settle a little. Come November 
18th, I'll be on vaccation until next year, when I'll do the first 2.5 refresh 
before rollout starts. How are your cats? Are you travelling again?

Mit freundlichen Grüßen,
Barbara Nitz

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List  Im Auftrag von 
Marna WALLE
Gesendet: Freitag, 29. Oktober 2021 15:05
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: Serverpac installs January 2022 and beyond - Issues

HI Barbara,

==>  I did a 'save as' in the browser and saved the html pages to my laptop. I 
expected the content to be on my laptop, but it wasn't. When I opened the html 
pages using notepad, there was some small crap in it that was way too small to 
be the information I had seen online. I actually had to go back and search for 
the link again, save that to my bookmarks and  read online. When I skipped a 
few chapters, it took forever to load the intended content. It felt like that 
content had a lot of external links in it that would explain why it was so slow.

Ugh...this is because of IBM Documentation.  It was supposed to give you an 
excellent HTML file of the content you were looking.  Alias, that doesn't 
happen. I've reported the problem, but do feel free to also provide feedback to 
urge the solution along faster.

I know you don't have z/OSMF up yet, but for those that do want that nice HTML 
file, you only need the core functions of z/OSMF to get you far enough to 
create the Upgrade Workflow there, and then export it. Before you export it, 
you can tailor it nicely for your system to make it much smaller than otherwise 
it would be.

-Marna WALLE
z/OS System Install and Upgrade
IBM Poughkeepsie

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




KfW / Sitz: Frankfurt am Main
Vorstand: Stefan Wintels (Vorsitzender), Dr. Ingrid Hengster,
Melanie Kehr, Christiane Laibach, Bernd Loewen, Dr. Stefan Peiss
Verwaltungsrat: Bundesminister Olaf Scholz (Vorsitzender)
Datenschutz <https://www.kfw.de/KfW-Konzern/Datenschutz.html>

-Disclaimer-
Die in dieser E-Mail und den dazugehoerigen Anhaengen (die Nachricht)
enthaltenen Informationen sind nur fuer den Adressaten bestimmt und koennen
vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Sollten
Sie die Nachricht irrtuemlich erhalten haben, loeschen Sie die Nachricht
bitte und benachrichtigen Sie den Absender, ohne die Nachricht zu kopieren
oder zu verteilen oder ihren Inhalt an andere Personen weiterzugeben. Ausser
bei Vorsatz oder grober Fahrlaessigkeit schliessen wir jegliche Haftung fuer
Verluste oder Schaeden aus, die durch virenbefallene Software oder E-Mails
verursacht werden.

-Disclaimer-
The information contained in this e-mail and any attachments (the message)
is intended for the addressee only and may contain confidential and/or
privileged information. If you have received the mess

INIT terminated at end of memory

[Barbara Nitz]

Apparently we ran into another of those PDSE latch contention bugs. While 
terminating the holder of the latch, we had to force the batch job since cancel 
had absolutely no effect.

We got messages
IEF743I INIT FORCED - CODE SA22 - IN ADDRESS SPACE 0040
IEF743I AUTO39P  FORCED - CODE SA22 - IN ADDRESS SPACE 0040
$HASP310 AUTO39P  TERMINATED AT END OF MEMORY
$HASP310 INIT TERMINATED AT END OF MEMORY

According to the books, IEF743I means "System action: The job and address space 
end." Unfortunately that does not seem to be the case. There is no indication 
that I can find in hardcopy log that the address space (Initiator) got 
restarted, and the dump that I took 17 minutes later shows the address space 
still up with ASCBEWST (address space last lost control) about 1s after 
$HASP310 INIT TERMINATED AT END OF MEMORY. I do see the initiator restarted 
25 minutes after.

I don't have a batch job that is non-cancelable, so I cannot test the force 
command on a batch job running in an initiator. Does anyone know for sure how 
memterm processing due to force goes for an initiator? Does the initiator 
really terminate?

Our problem turned from Latch contention into ENQ contention, with that INIT 
holding a vital ENQ and not releasing it.

Thanks and regards, Barbara

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

Re: INIT terminated at end of memory

[Barbara Nitz]

Hi Greg,

>A FORCE command becomes a CALLRTM TYPE=MEMTERM request which will drive
>address space level resource manager routines in the *MASTER* address
>space for the memterm'd address space.  Ideally a resource manager
>routine should never need, or at least wait for, serialization of a
>resource during its processing.  But the ideal is rarely the reality,
>and resource manager routines can, and often do, get delayed or
>deadlocked.

I am guessing that this is what happened here. When I wrote the management 
summary after analysis (after I had posted here), it seems as if the initiator 
*did* terminate, but about 20 minutes later after causing problems in 
production (the original latch contention was on an AD system):
D GRS,CONTENTION,ENQ
ISG343I 11.30.00 GRS STATUS 419 
S=SYSTEM  SYSZRACF SYS1.RACF.BACK   
SYSNAMEJOBNAME ASID TCBADDR   EXC/SHRSTATUS 
AWE2  CTSACS 010F   009C68F8 EXCLUSIVEOWN   
AWE2  MIMGR  00CF   008E2398 EXCLUSIVEWAIT  
S=SYSTEM  SYSZRAC2 SYS1.RACF
SYSNAMEJOBNAME ASID TCBADDR   EXC/SHRSTATUS 
AWE2  INIT   0040   009FF6C8 EXCLUSIVEOWN
AWE2  TCPTNS01   00DC   009CAE88   SHARE  WAIT  
AWE2     0030   00919838   SHARE  WAIT  
AWE2  INIT   00B2   009FF6C8   SHARE  WAIT  
S=SYSTEM  SYSZRAC2 SYS1.RACF.BACK   
SYSNAMEJOBNAME ASID TCBADDR   EXC/SHRSTATUS 
AWE2  CTSACS 010F   009C68F8 EXCLUSIVEOWN   
AWE2  INIT   0040   009FF6C8 EXCLUSIVEWAIT  

After I had forced CTSACS out of the system, the dump I had taken (of the GRS 
address space only) finally came through and got written out. And I found 
IEF403I INIT - STARTED - TIME=11.44.01 for the initiator in question right 
after the force completed. It is quite possible that the contention in 
production started to resolve itself at this point, but we all were rather 
frazzled and had already decided to reIPL the system.
 
I am guessing that CTSACS was caught up in the parallel Unix Latch contention 
we had that does not show up on any D GRS,C  or D GRS,LATCH,C displays. (That 
address space uses USS due to IP connections to work stations.) I also cannot 
find latch contention information in my dump, although there definitely was 
some at that point.

>RTM *does* monitor resource manager routine execution (Paul and I added
>this support many years ago), expecting the task it is running under to
>have executed something across an interval of time.  If two intervals
>pass without any execution occurring then RTM will ABTERM the task with
>an ABEND 30D (
>).
>
>It sounds like an address space level resource manager routine became
>hung, possibly due to the same latching issue you issued the FORCE for.
>I suggest you check in LOGREC for any ABEND 30D records during the
>interval to see if a hung resource manager routine was detected by RTM,
>and go from there.
No abend30D in logrec, and aside from my dump of GRS no other dump, either. 
Traditionally, this installation has never had sadump configured or I would 
have taken one. (I plan to fix that this year!)

Interestingly enough, ASCBEWST from CTSACS in my dump shows a timestamp of 
11:08. At 11:04 we had the first IGW038A Possible PDSE Problem(s) (SMSPDSE1) 
and at 11:05 we had the first BPXM123E UNIX SYSTEM SERVICES HAS DETECTED THAT A 
GRS LATCH HAS BEEN HELD BY JOB xx FOR AN EXTENDED PERIOD OF TIME.

And yes, we definitely had PDSE Latch contention, and *something* was very 
wrong. Note that there is no data set name in the display:
V SMS,PDSE1,ANALYSIS
IGW031I PDSE ANALYSIS  Start of Report(SMSPDSE1) 214  
-data set name-- -vsgt--- 
  01-ASPIL0-00011C
++ Unable to latch DIB:7E9BE0A0   
  Latch:7F7D5F08 Holder(0040:009C7248)   
  Holding Job:AUTO39P
  CallingSequence:IGWLHJIN IGWDACND IGWDBPAR IGWFARR3
++ Unable to latch LSDLTDW:7F6BF680   
   Latch:7F6BF798 Holder(0040:009C7248)   
   Holding Job:AUTO39P
++ Lock GLOBAL DIRECTORY SHARED   
held for at least 842 seconds  
Hl1b:7F7D5DB0 HOLDER(0040:009C7248)
Holding Job:AUTO39P
 ++ Lock GLOBAL FORMATWRITE SHARED 
held for at least 842 seconds  
Hl1b:7F7D5DB0 HOLDER(0040:009C7248)
   Holding Job:AUTO39P  

SAS user abend code documentation?

[Barbara Nitz]

We are currently experiencing abend u1335 in SAS 9.4_m3 in different jobs. My 
first step would be to determine what that user abend actually tells me - but I 
cannot find the book containing the abend code meanings. Does anyone know what 
book contains that information? 

(We already have a ticket open with SAS, and we were told to make sure that the 
users have an OMVS segment because they don't. Well, they DO have an OMVS 
segment, and it is old news that bpx.default.user doesn't work anymore under 
2.1)

Thanks, Barbara

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

Re: SAS user abend code documentation?

[Barbara Nitz]

>Have you seen this http://support.sas.com/kb/54/206.html

Chuck,
yes, we did. And we are at a higher maintenance level already. One of the 
problems is that u1335 seems to occur in all kinds of problems, which is why I 
want to see what it actually *means*.

Barbara

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

Re: SAS user abend code documentation?

[Barbara Nitz]

>We don't document internal abend codes as the vast majority will
>(hopefully) never be seen. They can change from release to release
>and even at a maintenance release. They're used when the program
>can't continue to run for some reason. Usually, they are accompanied
>by a message to the SAS log, but not always. The expected result is
>that the customer will open a problem ticket. Sometimes, just the
>abend code and a description of the job will be enough to shoot the
>bug, but sometimes a dump is required.
>
>For u1335, you should have seen 'Free buffer overwritten.' in the
>log. It just means that our internal heap has been corrupted. We
>look for an eyecatcher on the linked-list of free blocks and if
>it's not there, abend.

Thanks Don,

yes, we had that 'free buffer overwritten' in the log. Which is why I really 
don't understand the relation to the RACF question (and the SAS admins also 
don't understand it). And yes, the default group for all the users has a GID 
(and an OMVS segment).

Should we send the huge sysudump to SAS that got written? Apparently all the 
jobs (both in prod and in AD) are doing similar things, and the exact same job 
runs 'after sunset'.

Barbara

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

Re: AW: Re: Seeking for help finding cause of S23E/S53E with preceeding S202, and PGM 011/004

[Barbara Nitz]

>a) I see a couple of FREEMAIN (SSRV 78) trace entries pointing to a TCB in 
>read/write nucleus (TCB address is 00FDD4F8). Do these hold some useful 
>information for me?
The only tcb I know of that actually, really is located in the R/W nucleus is 
the first tcb in the *master* address space. Every address space started after 
that starts with a tcb in LQSA. So unless the SSRV entries were for asid(1), I 
would find a tcb address in R/W nucleus highly suspicious. Have you checked the 
storage FDD4F8? Is it really a tcb? (Easiest way to check is a cbf x'fdd4f8' 
str(tcb). If the eyecatcher is not there, the formatter will tell you).

b) I know "SVC D" is also entered for normal task termination. In an ld MVS 
debugging manual I found that the first byte of R1 is x'08' this indicates RTM2 
is called for task termination cleanup. The x'08 does no longer seem to hold 
true. How can I identify such an non-error an SVC D entry?
Error entries usually have an asterisk is front of the word SVC. I learned 
early on to do a "f '*'" in the trace table to find the entry for the abend. If 
you don't see the *rcvy entries following the svc d, chances are that you're 
looking at normal termination. Another indication is that IIRC normal 
termination doesn't have an abend code.

c) In some dumps I see "SVC 3" (exit) trace entries, sometimes I can see the 
"SVC 3E" (DETACH), sometime it is not in the trace.
What's the question on this? Did you format the trace table using 'jobname(your 
jobname)'? Given the number of dumps you had and the abend codes, there should 
be some form of common denominator. 23E and 53E are both detach abends, so I 
would expect to see an SVC 3E entry. Detach does some validity checking and 
then issues these abends. So at the time of detach you already have an overlay.
Always look at the earlieast error indication. Are there logrec entries for it? 
What is that error? If it is a pic11, check the earlier trace table in that 
address space for a freemain - sometimes it is a larger range that got freed. 
Does a summary format on the problem address space work without errors? Is 
there more than one tcb with a completion code?

Barbara

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

Re: Job hold on jes2 input queue

[Barbara Nitz]

RDT systems being based on ADCD distributions I suggest to discard all current 
JES definitions on that RDT system and cold start with a jes2parm similar to 
this (you'll need to adjust data set names and volumes):

BUFDEF   BELOWBUF=(LIMIT=100,WARN=80),   
 EXTBUF=(LIMIT=500,WARN=80)  
CKPTDEF  CKPT1=(DSNAME=SYS1.JESCKPT3,VOLSER=SYS001,INUSE=YES),   
 CKPT2=(DSNAME=SYS1.JESCKPT4,VOLSER=SYS002,INUSE=YES),   
 NEWCKPT1=(DSNAME=SYS1.JESCKPT1,VOLSER=SYS002),  
 NEWCKPT2=(DSNAME=SYS1.JESCKPT2,VOLSER=SYS001),  
 DUPLEX=ON,MODE=DUPLEX,LOGSIZE=2 
CKPTSPACE BERTNUM=4000,BERTWARN=80   
CONDEF   AUTOCMD=20,BUFNUM=1000,CMDNUM=800,DISPMAX=1000, 
 BUFWARN=80,CONCHAR=$
ESTIME   NUM=90,INT=90,OPT=NO
ESTLNCT  NUM=90,INT=5,OPT=0  
ESTPAGE  NUM=1000,INT=100,OPT=0  
ESTBYTE  NUM=99,INT=9,OPT=1  
ESTPUN   NUM=10,INT=2,OPT=0  
FSS(PRINTOFF)
INITDEF  PARTNUM=120 
INIT(1-6) CLASS=A,START=YES  
INIT(7-115) CLASS=A,START=NO 
INIT(116-120) CLASS=(SYSTEM),START=YES   
INTRDR   AUTH=(JOB=YES,DEVICE=NO,SYSTEM=YES),
 RDINUM=4
JOBCLASS(A-*) ACCT=NO,AUTH=ALL,BLP=YES,COMMAND=VERIFY,MSGLEVEL=(1,1),
TIME=(180,0) 
JOBCLASS(STC) AUTH=ALL,BLP=YES,COMMAND=EXECUTE,LOG=YES,MSGCLASS=K,   
  MSGLEVEL=(1,1),OUTPUT=YES,TIME=(1440,0),   
  SWA=ABOVE,OUTDISP=(HOLD,HOLD)  
JOBCLASS(TSU) AUTH=ALL,BLP=YES,COMMAND=VERIFY,LOG=YES,MSGCLASS=K,
  MSGLEVEL=(1,1),OUTPUT=YES,TIME=(180,0),
  SWA=ABOVE,OUTDISP=(HOLD,HOLD)  
JOBCLASS(SYSTEM) ACCT=NO,AUTH=ALL,BLP=YES,COMMAND=VERIFY,
 MSGLEVEL=(1,1),TIME=(180,0) 
JOBCLASS(CL) ACCT=NO,AUTH=ALL,BLP=YES,COMMAND=VERIFY,
 MSGLEVEL=(1,1),TIME=(180,0) 
JOBDEF   ACCTFLD=OPTIONAL,DUPL_JOB=DELAY,JCLERR=YES, 
 JOBNUM=6000,JOBWARN=80,PRTYJECL=NO,PRTYJOB=NO,  
 RANGE=(1-)  
LOGON(1) APPLID=RDT001,LOG=Y 
MASDEF   SHARED=NOCHECK,DORMANCY=(100,500),HOLD=100,LOCKOUT=1200 
NJEDEF   JRNUM=2,JTNUM=2,LINENUM=5,MAILMSG=YES,  
 NODENUM=15,OWNNODE=1,PATH=1,SRNUM=2,STNUM=2 
NETSRV(1) SOCKET=LOCAL   
NETSRV(2) SOCKET=LOCAL   
NETSRV(3) SOCKET=LOCAL   
LINE(1)  UNIT=SNA
LINE(2)  UNIT=TCP,NODE=9 
LINE(3)  UNIT=TCP,NODE=4 
LINE(4)  UNIT=TCP,NODE=11
LINE(5)  UNIT=TCP
NODE(1)  NAME=RDT001 
NODE(4)  NAME=,LINE=3  
NODE(9)  NAME=,LINE=2  
NODE(10) NAME= 
NODE(11) NAME=RDT002,LINE=4  
SOCKET() NODE=4,IPADDR=,NETSRV=1
SOCKET() NODE=9,IPADDR=,NETSRV=1
SOCKET() NODE=10,IPADDR=,NETSRV=1   
SOCKET(RDT002) NODE=11,IPADDR=RDT002,NETSRV=1   
OFFLOAD1 DSN=SYS1.OFFLOAD   
OUTCLASS(A-*) OUTDISP=(HOLD,HOLD)   
OUTCLASS(B)   OUTDISP=(WRITE,WRITE) 
OUTCLASS(F)   OUTDISP=(WRITE,WRITE) 
OUTCLASS(L)   OUTDISP=(WRITE,WRITE) 
OUTCLASS(Z)   OUTDISP=(PURGE,PURGE) 
OUTDEF   BRODCAST=NO,DMNDSET=YES,JOENUM=25000,JOEWARN=80
OUTPRTY(1-*) PRIORITY=96,RECORD=16677215,PAGE=16677215  
PCEDEF   CNVTNUM=2,OUTNUM=4,PURGENUM=2  
PRINTDEF CCWNUM=10,FCB=EX01,LINECT=70   
PUNCHDEF CCWNUM=02  
SMFDEF   BUFNUM=5,BUFWARN=80
SPOOLDEF DSNAME=SYS1.JESSPOL,TGSIZE=100,TRKCELL=3,  
 TGSPACE=(MAX=162880,WARN=80),VOLUME=JES00  

Re: Paging subsystems in the era of bigass memory

[Barbara Nitz]

>I don't want to turn this into a debugging session, but this is what I see in 
>RMF3 on the non-DB2 utility system. 
>All of the TPX 'regions' are below this list sorted by Aux Slots. No task 
>shows any page-ins.

Not sure that you haven't already done this: Use IPCS active on that system, 
and use either ip ilrslotc or panel 2.6i. It'll show you exactly which address 
space paged out anything to aux (to whatever medium).
I recall that in a prior life I could see exactly which asid had a lot of 
frames on aux (MQ, I think).

Since we upgraded to the z13 we increased real drastically on all lpars. 
Recently,  we also started using SCM (flash express). The only thing we were 
baffled by was the fact that we still needed *one* local page data set to 
satisfy the system. Other than that, we're very happy with SCM (where we 
already have it active). 

Now, to tune sort so that it doesn't need 20 Mod54s as sortwrk anymore when SAS 
wants to sort 1.600.000.000 records.

Barbara

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

Re: SLIP with ACTION=NOSUP

[Barbara Nitz]

Peter,

go into IPCS, option 3.5. Then put a t for takedump in front of the symptom 
string. In the background, that will turn off DAE, set a marker and 
re-establish DAE. Make sure that your ADYSETxx members are properly customized 
and that you have ADYOPCMD in the authorized command section of IKJTSOxx.

Barbara

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

Re: "New" Java-less Operating System Messages blips like crazy

[Barbara Nitz]

>I'm trying to use the new Java-less Operating System Messages console on
>the HMC.  My version is Blippy McBlipperson, which makes it extremely
>difficult to use, because you can't watch it.  As new messages are sent
>to the console, the display collapses and expands at least 10x/sec.
>Anybody else's HMC console behave this way?  If so, what was IBM
>thinking?  We had to submit RFE's to get them to remove Java, do we have
>to submit more requirements to make it usable?

Same here; ever since we got the z13, it is essentially impossible to see NIP 
messages because the console doesn't scroll anymore. The first screen fills and 
then just blips, no new messages, and no scrollbar. When I reported it, it was 
implied that this was due to my 'failure' to use the tree-style interface.

I have resorted to using the 3270 console. Which has the disadvantage that you 
cannot scroll back. But at least I see the NIP messages.  After a while (and 
after closing the OSM screen and reopening it), the OSM screen actually gets a 
scroll bar. Never mind that the buffer is so small that the first messages have 
already gone. IBM was unable to tell me how to increase that buffer size. 

I am glad that I am not the only one who sees this.

Barbara

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

Re: "New" Java-less Operating System Messages blips like crazy

[Barbara Nitz]

>I opened a hardware issue for this same reason and hardware support reported 
>that MCL patches needed to be applied to the HMC.  Those patches were recently 
>put on but I haven't had a chance to be at the HMC during a sandbox IPL to 
>verify if it is fixed.

When I first detected this last year, I had asked my colleague who does 
'hardware' to open a ticket and provided him with documentation for it. He just 
didn't open the PMH. And I had the bypass of using the 3270 console. Until we 
hit the point in IPL where thousands of V offline commands spit out their 
response (don't ask!) and it took more than 10 minutes to see 'real' 
information again, even at rtme=1/4. I have asked my colleague again for that 
PMH as a result of this thread. 

I have also told him about the MCL patch and asked that he asks IBM which patch 
will fix it. (We may have it on already, though). 

As for Browser: IE is the corporately mandated browser, and I heartily distrust 
anything having to do with google, so I don't use Chrome. No way to change 
anything in IE, either. I could not even find where to customize compatibility 
mode. There is nothing mentioned in that one menue that I found.

Barbara

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

Formatting a ZFS

[Barbara Nitz]

I am fighting with USS. Again.

I am installing HCR77C0 and am trying to get a ZFS formatted:
//ZFSALLOC EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSINDD *   
DEFINE CLUSTER( - 
   CONTROLINTERVALSIZE(26624) -   
   NAME(INSTSMP.ICSF.HCR77C0.SCSFHFS) -   
   LINEAR CYLINDERS(100 50) -
   SHAREOPTIONS(3) -  
  )   
//ZFSFORMT EXEC PGM=IOEFSUTL, 
// PARM='format -aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS -version5'
//SYSPRINT DD SYSOUT=*

IDCAMS output:
IDC0508I DATA ALLOCATION STATUS FOR VOLUME INST00 IS 0   
IDC0508I DATA ALLOCATION STATUS FOR VOLUME *  IS 0   
IDC0508I DATA ALLOCATION STATUS FOR VOLUME *  IS 0   
IDC0512I NAME GENERATED-(D) INSTSMP.ICSF.HCR77C0.SCSFHFS.DATA
IDC0181I STORAGECLASS USED IS x
IDC0181I DATACLASS USED IS y  
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0

IOEFSUTL output:
HLQ INSTSMP is SMS-managed now (but I got the same error when it wasn't SMS):
Version 02.01.00 Service Level OA50873 - HZFS410.   
 
IOEZ00760I No IOEZPRM DD specified. Parmlib search being used.  
 
IOEZ4I Formatting to 8K block number 1300 for primary extent of 
INSTSMP.ICSF.HCR77C0.SCSFHFS.
IOEZ00337E zFS kernel: non-terminating exception 2C3 occurred, reason EA0B0248 
abend psw 77C1000 906814A2
IOEZ00033E FSUTL: could not open trace output dataset   
 
IOEZ00334I Return code and reason code for dump is 4000 
 
IOEZ00598E Error 157 reason code EFE16137 received formatting aggregate 
INSTSMP.ICSF.HCR77C0.SCSFHFS 

There is an SVCdump written. Every time I reran the job. Needless to say - I 
was unable to find documentation for the reason code(s) received, much less any 
hint what might be wrong. This job used to work, last on a system without the 
'refreshed' maintenance in (January of this year). Didn't find any ptf which 
might describe my problem.

Using this for formatting
//ZFSFORMT EXEC PGM=IOEAGFMT,
// PARM='-aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS -compat'
//SYSPRINT DD SYSOUT=*   

gets me IOEZ00207E Aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS was not found

which isn't really helpful ("An attempt was made to attach or format an 
aggregate, but no VSAM linear data set could be found
with the given name.")

Does anyone have an idea what might be wrong or do I really have to go through 
the crap named SR?

HFSs still work like a charm

Barbara

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

Re: Formatting a ZFS

[Barbara Nitz]

>Weird one.  Since IOEZPARM is saying 8K block, I'd try CISIZE(8192).  If
>it still doesn't work, scheisse zeit.

Bingo. The collective wisdom of this group is great! With 
CONTROLINTERVALSIZE(8192) I get the same problem as before, so I left it off 
completely (as Peter suggested), and the ZFS formatted just fine. I may have 
found this myself at a later date, since the job (without CISIZE) ran on 
another sysplex and I may have seen the difference one of these years. I don't 
know why I had this parm in in the first place.

Thanks for the good laugh, Tom!

Now exit, stage left, muttering: Why didn't IBM just specify in plain English 
that one cannot determine CISIZE instead of using an obscure, undocumented 
reason code and an unhelpful amount of dumps and messages?!?!?

Barbara

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

Re: Formatting a ZFS

[Barbara Nitz]

TSO BPXMTEXT EA0B0248

BPXMTEXT does not support reason code qualifier EA0B  

That was the first thing I tried.

Barbara

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

Re: AW: Re: Formatting a ZFS

[Barbara Nitz]

>Would you mind, and do you have time to open a PMR? If zFS cannot cope with 
>non-default CI size, it should say so clearly when asked to format a new 
>cluster. At the very least, the 0248 reason code must be documented.

Amen.

But I really really really hate SR, so I really want to avoid opening one 
(horror!) and then spend an enourmous amount of time 'discussing' with IBM 
support (that in my experience) has deteriorated a lot from the 90s (some 
exceptions noted) when I was IBM support myself. Especially now that I have 
solved the problem with all of your help. We don't have a direct internet 
connection, so the thought alone of sending off the dump after tersing it gives 
me the hives. I just don't have the time to spare. I am also sure that a lot of 
sysprogs feel the same way about SR.

Also, while investigating this, I found other apars that said 'ZFS needs to 
document reason codes'. Apparently IBM hasn't learned anything from that and 
still does not document reason codes.

Also, while investigating, I tried some variants of direct commands inside 
OMVS. Inside OMVS gave me 'command not found' (and I don't have the knowledge 
or the time to figure out how to make it find it). And when I tried the 'tools 
- run shell command' from inside ishell, I got the same unhelpful 'dataset not 
found' that I got using the batch job. Admittedly, I didn't try to *define* the 
dataset that way, just to format a non-conventional VSAM LDS. I just didn't 
know that it was unconventional at the time.

In any case - all of this will make for an interesting 'user experience' 
presentation at the zTU in Munich in October. Or so I hope.

Barbara

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

Friday question: ISPF Statistics Manipulation

[Barbara Nitz]

A colleague of mine just asked me if ISPF statistics in a data set, especially 
the USERID field, can be manipulated. We used ISPF 3.5 and we were both 
astonished that I was easily able to fake a userid as the one who last changed 
a member (testing in my own dataset, of course). 

This immediately raised the question for me if there is any RACF control that 
would prevent this type of manipulation, especially since the userids in those 
statistics are widely used as evidence. Does anyone know if there are such RACF 
controls? A quick search in the ISPF books didn't turn up any hint.

Barbara

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

Re: Friday question: ISPF Statistics Manipulation

[Barbara Nitz]

>Evidence of what Barb ? Don't hang anyone on this evidence. Anyone with
>update access to the pds can update this field..

My colleague asked me on Friday if it is possible to fake the ISPF Statistics. 
I already knew that you can write them yourself using something other than 
ISPF. So we tested how easy it would be to change them. Apparently in a former 
life my colleague was blamed for an error because his name was in that 
statistics field as the one who last changed, and he had never seen that member 
or that content before.

Last year I was asked if the powers that be can use ISPF statistics as tracking 
who had changed a source code library (on a regular basis, and please no plugs 
for source control products!). I pointed them to ISPF 3.5 then and to the fact 
that STATS OFF will delete existing statistics. Fortunately my answer 
discouraged them enough so they didn't follow this scheme any further. I 
nevertheless do have STATS ON in the global (system) ISPCCONF. Which you can 
not use by using your own, preconcatenated version.

That's what I mean by 'used as evidence'. And I wondered if it is just my 
ignorance or if there really is no way (as I suspected) to prevent unauthorized 
changing of the statistics. 

Thanks to all who answered.

Barbara

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

Re: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[Barbara Nitz]

>But is it a valid data point?  We use z/OSMF only insofar as we are forced to 
>for IP configuration and upkeep.  We did not use z/OSMF to install v2.2, and I 
>don't know whether we'll use it to install v2.3.  There is talk of it, but it 
>seems to be largely motivated by the thought that we will be forced into it 
>(kind of like zFS).  
>
>Don't get me wrong, we've had talks... I'm with simple and common software 
>management processes, and I'm glad to see ISVs on board, but I'm not convinced 
>that z/OSMF in and of itself is either necessary or sufficient to achieve the 
>goal.  If you have good SMP/E packaging, z/OSMF is unnecessary as an 
>installer.  If you have crappy SMP/E packaging, front-ending it with z/OSMF 
>will not be sufficient to address the shortfall.
>
>I don't see the need for z/OSMF for software deployment.  We have plenty of 
>experience here, and are easily passing that along to our newer sysprogs.  I 
>recoil at the thought of using it for configuration.  ISPF is sufficient to 
>edit PARMLIB, et al, and it runs in a WS client, if you so choose.
>
>Seems to me, any of the substantive improvements offered by z/OSMF ought to be 
>UI-agnostic.  It doesn't take a "sticky" UI and and the overhead (FSVO 
>minimal) of a server address space to improve product installation.  These 
>might have been made accessible ServerPac, or even the SMP/E dialogs, but they 
>weren't.  It's a fine thing for someone who wants the trouble of installing 
>and configuring Liberty et al (and I've heard the cursing all the way from 
>Austin and Phoenix), but ISPF apps ought to continue as supported options for 
>those who prefer them. 

Amen to that, from the bottom of my heart. 

I managed to configure ATTLS at z/OS 2.1 just fine without z/OSMF, and 
eventually understood what needs to get done and how things work together, and 
I will certainly not activate z/OSMF under z/OS 2.3. It will be just so much 
more dead weight on the sysres - together with all the useless fonts that were 
pushed down our throats, as far as I am concerned.

From the timetable John has sketched in that presentation - it may well be that 
I will have to use the deadweight to install z/OS 2.5 in 2021. Retirement 
cannot come soon enough!

As far as enforcing naming conventions go - we just had that exact same 
discussion here when a vendor naming convention wants to enforce &sysclone. 
usage when that symbol has never been used here. And I am fairly sure that all 
the so-called simplification within z/OSMF will just take away the 
configuration choices that we have grown used to to make all systems look like 
what IBM envisions. 

Barbara

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

Re: z/OS holddata per https?

[Barbara Nitz]

>I notice these are now available from:
>

Yes, I found that out when I needed the lastest holddata. I had forgotten to 
use IE (as long as we still have that) and had used Edge (no Firefox, no Chrome 
here) and it worked. Now I can only hope that IBM will no longer put ptf 
documentation inside a ++HOLD DOC as ftp links or as links to public data 
stores. IE will go away here soon and access to data stores gets blocked every 
time.

IBM has converted a number of ftp links to https now. Maybe my public complaint 
in January helped. 

Regards, Barbara

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

Re: z/OS holddata per https?

[Barbara Nitz]

>Does Edge force the HTTPS-Only Mode that Joel mentioned?
I have no idea. We are completely kneecapped and *have to* use what someone 
else configured.

>What's a "data store"?  Will downloads of HTTPS resources be prohibited?
>What about ShopZ and RECEIVE ORDER?

ShopZ has offered HTTPS for quite a while, so ShopZ has never been a problem. 

As for 'data store': I am unsure of the correct word. I mean the places 
somewhere in the cloud (even if the word ibm appears in the url) where just 
about everyone can store things and see it. It is kind of public, I think. Our 
installation generally prohibits us from accessing anything in these places, so 
there it doesn't matter if it https or not, we cannot get there as it is 
considered 'dangerous'. There seems to be a general list of IP addresses for it 
somewhere, maintained by whomever, so that gets blocked by the firewall.

Barbara

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

Re: Where is the DFPISMKD utility to run the DFPMKDIR EXEC?

[Barbara Nitz]

>Probably something new in the new zOMF fun world?
No, I think it's just a totally screwed up ptf.

> /usr/lpp/dfsms/hsm/config/
...
> /usr/lpp/dfsms/dss/IBM/
From the path names I am guessing that it is the same ptf that I have a PMR 
open with IBM. I never installed it into 2.3, assuming it would be correct in 
2.5. Well, I ordered 2.5 in early October, and the ptf still would not go in 
because it was missing the DDDEF statement to these pathes. IBM corrected that 
sometime in November for the serverpac, which was too late for me. Strangely 
enough, the pathes were already there (probably due to another error).

The DDDEFs come in another ptf and you are required to put them in manually. 
Unfortunately, they don't contain a statement for the DLIB zone. That's what my 
PMR is all about. Where will the thing get accepted to? Has anyone (who has 
already applied the ptf) tried an accept check on it? I asked IBM where it will 
get accepted, and I haven't gotten an answer for over a month now. So far I 
haven't installed the ptf. 

Regards, Barbara

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

Re: Where is the DFPISMKD utility to run the DFPMKDIR EXEC?

[Barbara Nitz]

>I encountered this issue while applying maintenance to z/OS 2.4.I opened a 
>ticket to IBM, and found that there is another PTF, OA60532(UJ05094), which 
>needs to be applied first, so that the stuff needed for DFPISMKD to run the 
>proper DFPMKDIR appears in SYS1.SAMPLIB. 
>
>Following this path worked fine.   IBM did publish a tech-note based on my 
>question:  https://www.ibm.com/support/pages/node/6540628
>
>Apparently UJ05471 has  ++PREREQ for UJ05094,  but this doesn't pop out in any 
>way,  if both PTFs are being apply-check'd in the same package.

The ptf that I haven't applied yet is uj05895 (z/OS 2.5). 
At z/OS 2.3, there first wasn't a dddef to even apply the ptf. Then the paths 
were missing, that's what the utility is said to be used to build the paths. 
The dddefs are another ptf, IIRC.
As Ann said, when you apply check them at the same time, you see nothing. You 
have to first read all hold actions and do them before applying. And I don't 
have an answer from IBM to my question where uj05895 *accepts* to. The ptf that 
provides the dddef for the apply does not have dddefs for accept.

Barbara

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

Re: System Dump DS's

[Barbara Nitz]

>That's correct.  I didn't delete mine either, I just made them very small.

IIRC, the system dump data sets should not be deleted. Dynamic dumps require 
SMS to be active. Before SMS is active, no dump can be taken when the old-style 
dump data sets are not available anymore. 

I remember one occasion where MSTJCL failed to start. The system did not go 
into a wait state, but it did not come up, either. Without that old-style dump 
I would never have found the problem - accidentally ISPF compress was used on 
the parmlib member. That resulted in a lot of gibberish, but no comprehendable 
JCL statements. Worst, when you checked mstjclxx via ISPF, it looked completely 
okay. 

Better keep your old-style dump data sets to be used until SMS is fully active.

Regards, Barbara Nitz

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

Re: z/OSMF and Health Checker butting heads

[Barbara Nitz]

Tom,

speaking for consoles: For at least the past 25 years the 'reasonable' standard 
has been just what the health check tells you:
- Do NOT send all routing codes or all routing codes except 11 (programmer 
information) to either the consoles or the hardcopy log.
- Do NOT configure the MSCOPE for messages so that they automatically get sent 
to another system. This is a performance issue.
I believe that that is even documented.

I have my consoles  set up like this (we don't have MCS consoles anymore):

DEFAULT ROUTCODE(1-10,12-128) HOLDMODE(YES)   
CONSOLE DEVNUM(SYSCONS) ROUTCODE(1-10,12-128) INTIDS(Y) LEVEL(ALL)
UNKNIDS(Y)
CONSOLE DEVNUM(HMCS) NAME(HMCS&SYSNAME.) AUTH(MASTER) MSCOPE(*)   
INTIDS(Y) LEVEL(ALL) UNKNIDS(Y) ROUTCODE(1-10,12-128) 
PFKTAB(PFKTAB1) TIMEOUT(10)   

Both SYSCONS and HMCS are represented as EMCS consoles in the system. Both 
definitions violate the rule 'all routcodes except 11'. That may be the reason 
I deleted the health check. (Since I did the delete when we still had MCS 
consoles, I may need to revisit that deletion). As far as I am concerned, 
syscons and HMCS are only seldom active and I need to see what's going on and 
cannot limit the route codes to (1-10,12-16) for these two consoles.

In another shop we had one product that *required* MSCOPE *ALL. We identified 
the messages that were needed there, gave them a certain routing code and set 
the product console (admittedly an MCS console) to only receive that routing 
code. That console then got MSCOPE(sys1,sys2,sys3,sys4). At the time, that 
seemed to satisfy the check (IIRC).

As far as I know, z/OSMF communicates via EMCS consoles. For EMCS consoles, you 
can set attributes via RACF parm. Unfortunately, when the product defines and 
activates the EMCS console, it can overwrite what you had RACF-defined. We 
don't run z/OSMF (yet), so I cannot check for myself, but I am guessing that 
z/OSMF has either MSCOPE *ALL or all routing codes or both hardcoded. If that 
is the case, then you should open a PMR with IBM and ask them why z/OSMF 
violates best practises. 

If you delete the health check (as I did), just make sure that all your MCS 
defaults are 'reasonable' as stated above and that you don't have other 
products that set EMCS consoles with ROUT(ALL) and MSCOPE(*ALL). And remember 
that these two settings are really really bad for performance, as all messages 
need to get sent via XCF to all the systems.

Having said all that, which consoles are shown when you do the requested 
commands:
DISPLAY CONSOLES,L,FULL 
DISPLAY EMCS,FULL,STATUS=L
Are they all z/OSMF consoles? Or are there several products involved?

Best regards, Barbara

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

Re: z/OSMF PSWI

[Barbara Nitz]

>Create SYS1.IEBCOPY(IEBCOPY)?
>
>> Maybe, somewhere in the middle, IEBCOPY is relocated...

Or a ptf hit the ibm command processor, so each and every command issued 
abends

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

Re: z/OSMF PSWI

[Barbara Nitz]

>What I see is that z/OSMF development is following the same path as all of the 
>other 'lets get modern' projects.   You pick the pretty GUI you like and start 
>applying that toolset against a currently working 'solved' problem.   
>Promising modernization according to latest hot topics in code development.
>Buzzwords come and go, languages come and go, software development kits come 
>and go ad infinitum.
>
>What tends to be forgotten are all the time and effort spent on building the 
>solution to the old solved problem.   I can remember many discussions here and 
>elsewhere about ServerPac changes and difficulties that could benefit by more 
>development changes.   
>
>Who remembers all the IBM and OEM 'assistance' products created to buffer us 
>poor feeble support teams from the evils of SMP or SMP/E.  
>
>z/OSMF is just the latest way to 'dumb down' the complexities for the masses.  
>  But then reality steps in.   Somebody, Somewhere HAS to know what has to 
>happen when the rubber meets the road.   And navigating from the GUI through 
>the stack of products to get to the Road is a long and twisted path.
>
>IF (a big IF) you think the same way the GUI developer thinks, then life can 
>get smoother.  Any attempt to repeat the processes that were repeatable and  
>have worked before will meet resistance.   
>
>With the removal of old options like ServerPac and being forced to the new 
>paradigm  of z/OSMF will eventually lead to a better z/OSMF tool.  But lood 
>for years of development just like ServerPac needed to achieve its popularity.
>
Amen.

If I still had to install a new z/OS version before retirement, I'd go back to 
CBPDO. It's a bit more work because I have to do the apply myself, but it's 
tried and true, and I have used CBPDO on any product we have had to install 
except z/OS itself (Java, the compilers,  ...)

Regards, Barbara Nitz

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

Re: CAS Restart during system startup

[Barbara Nitz]

Mark,

>We don't start it in COMMNDxx/IEACMDxx, z/OS starts it as part of the system 
>initialization process.

I take it that you mean the CATALOG address space. This has been so as long as 
I can remember: CAS starts in asid x'B' (I think) as a limited function address 
space to provide *some* catalog services to the IPL process. After other 
supporting address spaces have come up, CAS restarts itself as a full function 
address space in an asid with a much higher number. x'B' is left unusable for 
the life of the IPL. I believe this is described to some extent in the books 
and is also mentioned in SHARE presentations (with more details, IIRC).

Regards, Barbara

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

abend0D6-27 in IOSAS

[Barbara Nitz]

After installing maintenance to z/OS 2.5 during IPL we experience 4 Dumps in 
IOSAS, ending with message *IOS637E THE ZHYPERLINK MANAGER TASK HAS TERMINATED. 
ZHYPERLINK AVAILABILITY MAY BE AFFECTED.

We do not use zHyperlink:
IOS634I 11.13.17 IOS SYSTEM OPTION
ZHYPERLINK IS DISABLED

I checked the dumps: They're abendd6-27 (linkage index translation exception) 
in IQPJCST+x'106'. The recovery routine is IOSSILMT and belongs to zHyperlink.
The missing PC number is 1B04. None of the 1Bxx PCs are in the 2.5 system. They 
apparently get established by the PCIE address space, which is not started 
automatically and ends rc=16 when I attempt to start it. They are available 
under 2.3, where the PCIE address space got started by the system.

Has anyone experienced something similar? Why does IOSAS establish a zHyperlink 
task when zHyperlink is disabled implicitly in IGDSMS? Any idea why PCIE does 
not get started in z/OS 2.5? Did I miss a ++hold somewhere? We're on a z15, if 
that is relevant.

No, I haven't opened a PMR with IBM yet.

Thanks in advance, Barbara Nitz

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

Re: abend0D6-27 in IOSAS

[Barbara Nitz]

Replying to my own post:

Address space PCIE gets started automatically during IPL and comes up unless 
your RACF Administration decides to 'program control' (not via RACF, but the 
effect is the same) lmod IEFVH1 and then does not check the fallout or correct 
it. GTZ was also affected.
After fixing that and reIPL the problem was gone.

Regards, Barbara

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

Re: IEASYS problem

[Barbara Nitz]

>In either case, is possible to "functionally replace" IEASYS00 with other 
>members.

We have ieasys00 in our regular parmlib, overriding the IBM delivered one. All 
our ieasys00 contains is CLPA, meaning that we always IPL with CLPA. All the 
rest of the parms are in sysplex-/system-specific ieasys-members. So the 
requirement to read ieasys00 is fulfilled and we can start our system(s) the 
way we like.

Regards, Barbara

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

Re: DAE to stop dump suppression

[Barbara Nitz]

>I have a dump that is being suppressed by DAE. I am not experienced with IPCS 
>and DAE. How do I find out what dataset is being used by DAE and how do I 
>"remove" the dump in order to get the dump?

The name of the DAE dataset is set in your ADYSET00 parmlib member, parameter 
DSN. If you never customized it you're using the IBM supplied default from 
SYS1.IBM.PARMLIB which does not contain the DSN parm - so check the books for 
the default name. IEACMDxx should contain a command "t dae=00" executed at IPL.
You're going to need the ADYSET01 member, too, with suffix 01, to stop DAE.

To get a new dump for your problem, you will have to go into IPCS 3.5 and enter 
the name of your DAE dataset. You'll be shown a list of dumps that will get 
suppressed because their symptom string is in the DAE data set. You put a "t" 
(without the quotes) in front of the symptom string and press enter. t stands 
for 'takedump at the next occurance'. In the background z/OS will issue the "t 
dae=01" command to stop DAE, do its magic to mark the symptom string and then 
issue "t dae=00" to restart DAE. Make sure there aren't any RACF errors for the 
set commands.

The procedure is described in detail in the Diagnosis: Reference manual.

Regards, Barbara

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

z/OS holddata per https?

[Barbara Nitz]

Happy New Year to all of you!

my employer has decided that ftp is not allowed anymore anywhere. Today I tried 
to download the newest holddata from 
http://service.software.ibm.com/holdata/390holddata.html. The file I'm 
interested in (full data, plain text) is a link to 
ftp://public.dhe.ibm.com/s390/holddata/full.txt. This is an ftp-Link, and ftp 
is not allowed anywhere. I get a connection failed error, purely on our side. 
So no holddata :-(

Does anybody a link where these holddata are downloadable via http/s?

Best regards, Barbara

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

Re: z/OS holddata per https?

[Barbara Nitz]

Kurt,

>Not exactly what you asked for, but you can order and download the
>HOLDDATA, all with HTTPS, using SMP/E RECEIVE ORDER.  Read about it here
>(watch the wrap:
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.gim3000/dsetup.htm

I found SMPHOLD when I had already done the receive order. A colleague gave me 
a pax and a cp statement so this time around I can do my refresh. But: in 3-4 
months time I'll do the accept, and then I need fresh holddata so I don't 
accept anything gone PE in the meantime. Ditto for when we migrate to the z15 
this year. I should not have to order ptfs any time I need holddata, and I did 
not see a way in ShopZ to order only HOLDDATA.

So I take it that except for the ftp link on that page there is no other way to 
get holddata via http/s from a browser. I guess my boss will have to escalate 
this to management because in my opinion this threatens the stability of z/OS 
in our installation.

Thanks for your help,
Barbara

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

Re: z/OS holddata per https?

[Barbara Nitz]

>  RECEIVE
>ORDER(   
>ORDERSERVER(ORDRINFO)   
>CONTENT(HOLDDATA)   
> CLIENT(CLNTINFO)  
> )   

Thanks for that, Andy. I looked at the SMPE cmd reference and didn't see the 
solution.

We are a small enough installation that we only do z/OS maintenance twice a 
year, so there is really no need to receive orders/ptfs every day or at higher 
frequency. Mostly the reason is that the processes surrounding maintenance are 
extremely cumbersome and more hindrance than help.

If the powers that be cannot be convinced to allow access to the holddata ftp 
website, 'the process' has just become even more complicated.

Thanks and regards, Barbara

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

Re: Assembler - Authorized program debug

[Barbara Nitz]

On Thu, 25 Feb 2021 23:57:08 -0600, Ravi Gaur  wrote:

>Writing and debugging an assembler code which has MODESET instruction to 
>change key and while debugging it via IDF or Debug tool both abend with 
>S047(APF) issue. Anyone know a way to debug facility for code without using 
>IDF/Debug tool?

Set a  slip trap on s=047 and use IPCS to read the resulting sdump. 

Regards, Barbara

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

Re: BLS18160D Response

[Barbara Nitz]

On Sun, 28 Feb 2021 08:08:55 -0800, Ed Jaffe  
wrote:

>I don't experience issues displaying keys using DISPLAY(MACHINE) when
>responding 'Y' to BLS18160D.

Did you compare the keys with what rsmdata knows about the key of the page? I 
learned to use 'yes' to the BLS message and only to use the key for the page 
that rsmdata shows.

Regards, Barbara

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

ISF.CONNECT.*

[Barbara Nitz]

Something has changed with SDSFAUX between z/OS 2.1 and z/OS 2.3.

Under z/OS 2.3, each and every user gets a RACF Message when they access their 
part of SDSF (that's the primary RACF panel). That missing right is for 
ISF.CONNECT.system, which is described as access to SDSFAUX. None of those 
users have any need to execute function provided by SDSFAUX, so I see no reason 
to give them read in that profile. This did not happen under 2.1.
These users can work normally with SDSF after the ICH408I. The RACF error is 
mostly irritating to them and ugly.

Why is the check for that right not 'silent' like all the others?

Short of granting the right, is there any way to make the RACF message go away?

Regards, Barbara

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

Re: ISF.CONNECT.*

[Barbara Nitz]

I am curious: Why is Rocket Software defending missing SDSF actions and bad 
documentation??? Has IBM 'outsourced' the SDSFAUX server?

I am annoyed with the ISFTABL thing (which we addressed in our logon 
procedure), too, because that message was irritating all of us.

The ISF.CONNECT thing is much more irritating: When you customize SDSF, quite 
clearly the users only saw in the functions they were entitled to use. That was 
true up to z/OS 2.1. (Can't speak for 2.2 since we went straight to 2.3.)

I feel strongly that issuing the ICH408I for *every* user is not an RFE thing, 
it is a blatant error since we do NOT get ICH408I for all the other functions 
that the users are not entitled to. Besides, the message is bogus, since the 
not priviledged users all can work and do the same things that they always 
could. 

Rob, in case you are not aware: From a RACF point of view, users should ONLY 
see what they have to see. That is not only corporate mandate where I work, it 
is also a general principle that all banks in Germany are forced to obey. So 
needlessly allowing users to see/access things that they cannot use because the 
RACF test for ISF.CONNECT does not follow SDSF standards is against all usual 
practices. We have taken more than our share of calls because of that.

Since you cited the SDSF customization Guide: I went through it. And the 
wording 'SDSF SERVER' isn't clear at all, because that encompasses both the 
SDSF address space itself  *and* SDSFAUX. The rest of the occurences for that 
profile name are all as a second mandatory access right when some function 
located in SDSFAUX is used. That is also the way the ptfs I installed in 2.1 
(that gave us SDSFAUX) worked.

Given the reaction here (and since this is obviously a Rocket Software thing), 
I will not waste my time opening an RFE. I will just define that profile and 
then tell the auditors to take this up with IBM by showing the documentation.

Barbara

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

Re: RACF DATASET protection WHEN(SYSID)

[Barbara Nitz]

>So how do people protect the same dataset differently on various LPAR's, or is 
>it just not possible?
We had to make sure that the compilers do not run on a system that doesn't have 
licence=z/OS. We used when(sysid) in class PROGRAM, for the names of the 
compilers as the program name to be protected. The downside is that the data 
set name must be specified (that the program is loaded from), and every data 
set name must be mentioned in the rule in PROGRAM. So if anyone copies the full 
compiler data set to their own HLQ and calls it from there, it would work on 
*any* system in the sysplex. The upside is that most of those calling the 
compiler would not have a clue how to do that. We have an additional safeguard: 
The jobclass canned compile jobs run in only exists on one system.

How IBM expects a customer to make sure the compilers are only called on a 
licence=z/OS system is beyond me - RACF certainly doesn't have the appropriate 
instrumentation for it that I can see.

As for having prod and test in the same sysplex - we are still a MIM shop, and 
we have a devil of a time stopping that type of data set sharing between prod 
and test.

I think that you would have to duplicate your RACF data base and use different 
data set rules on the prod system(s) than on the test system(s). Which would 
not be easy to implement.

Barbara

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