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

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

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

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

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 message by mistake please
delete it and notify the sender and do not copy or distribute it or disclose
its contents to anyon

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

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]

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]

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]

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

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]

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

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

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

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

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

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

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

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

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

>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: 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: 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) 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: 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: 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]

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: 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: 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: 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. 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  LINKS ZFS since 
I normally refresh Java together with z/OS when  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: 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: 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: 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

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: 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: 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: 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: Clarification on DASD mod conversion of SYSRES

[Barbara Nitz]

>I just checked my master cat and EVERY entry has , 2, or 3 except
>SYS1.PARMLIB on the SYSRES It has **. and  both are set
>to  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 

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: 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)  (n>1) defined and would need to be 
catalogued to 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]

>I have never has a problem using  anywhere ** could have been used.
>Actually, the resolution of  occurs very early in the IPL, long before 
>CAS is initialized.
>
>The difference is that  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 
 (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  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  for the first logical extension 
to the system reference volume,  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  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]

>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 

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  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 
 to **, the system came up.

Has that changed in the meantime? Are  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: 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: 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: 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: 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: 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

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

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

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

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: AW: Where are the IBMLINK SIS fuinctions today?

[Barbara Nitz]

>And where can I look up PTFs? IBMLINK / SIS was my major website doing 
>this.
>The "Granular APAR search" doesn't work for me with PTF numbers.

What's wrong with SIS? I can get in and can do searches, just as always. My 
login link is 
https://www-304.ibm.com/ibmlink/servicelink/servicelink.wss?lc=de=DE
Obviously the DE would have to be changed for other countries.

Barbara

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

Re: Failing to install zOSMF ptfs

[Barbara Nitz]

>That’s correct Barbara.
And it worked like a charm. Which made me wonder why I was able to mount on a 
non-empty mount point (assuming it was non-empty!). Turns out I only had the 
parm set to warning, not to fail. And sure enough, there was a message that I 
mounted on a non-empty mount point. 

>You probably have some garbage IBM* modules in the SIZUUSRD filesystem now, as 
>SMPE would have placed them there, then tried to do the link(which failed).   
>After a successful apply without that FS mounted, you may have some manual 
>cleanup to do in that filesystem.
That should not be a problem. I guess the only thing that is supposed to be in 
there is the /data directory.

>I went back and looked at my (unused) Serverpac provided BPXPRMFS and see that 
>SIZUUSRD is mounted off of /var:
I should have done that instead of checking SMPE :-(

Thanks, David!

Barbara

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

Re: Failing to install zOSMF ptfs

[Barbara Nitz]

David,

>Are you sure you had all of your Service filesystems mounted correctly?  The 
>error indicates the possibility that maybe not?   On my systems IZUUSRD is 
>mounted off /var/zosmf and is NOT updated by SMPE as it is the ZOSMF 
>operational data container.   My V2.3 SMPE shows DDDEF SIZUFSD with a path of 
>'/SERVICE/usr/lpp/zosmf/IBM/' and when I mount my Service filesystems, and 
>navigate there, I see;

yes, I am pretty sure that I mounted correctly:

 /SERVICE/usr/lpp/liberty_zos   INST23.SBBLZFS
-/SERVICE/usr/lpp/zosmf/* 
  /SERVICE/usr/lpp/zosmf/IBMINST23.SIZUUSRD.N 

I think what you're telling me is that the SIZUUSRD.N ZFS doesn't need to get 
mounted at all. Instead I should just use the path that's there and install 
into the root. I'll try that tomorrow.

Thanks,
Barbara

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

Failing to install zOSMF ptfs

[Barbara Nitz]

What a good thing we are not using z/OSMF. Last Friday I downloaded a refresh 
for z/OS 2.3 from ShopZ. Everything went fine *except* ptfs UI55431, UI55737, 
UI56534, UI57065 and UI57212. They fail to go in.

I install maintenance into /SERVICE, so the root is mounted under /SERVICE. 
SBBLZFS is mounted under /SERVICE/usr/lpp/liberty_zos, SIZUUSRD is mounted 
under /SERVICE/usr/lpp/zosmf/IBM, just like the DDDefs from serverpac specified.

I get these errors:

BPXF151I BPXCOPY WAS INVOKED FOR HEAD ID 09.
   
BPXF150I MVS DATA SET WITH DDNAME SYSUT1 SUCCESSFULLY COPIED INTO TEXT HFS FILE 
/SERVICE/usr/lpp/zosmf/IBM/IZUGUTSC.   
BPXF140E RETURN CODE 0090, REASON CODE 0549010C.  A LINK FAILED FOR LINK 
NAME /SERVICE/usr/lpp/zosmf/IBM/../samples/IZUSEC.xml.
BPXF151I BPXCOPY WAS INVOKED FOR HEAD ID 10.
   
BPXF150I MVS DATA SET WITH DDNAME SYSUT1 SUCCESSFULLY COPIED INTO BINARY HFS 
FILE /SERVICE/usr/lpp/zosmf/IBM/IZUSPEAR. 
--- 
   
SHELL SCRIPT IZUSPUNE OUTPUT FOR HFS IZUSPEARSEQ NUM 11 
   

   
/SERVICE/usr/lpp/zosmf/IBM/IZUSPUNE: /SERVICE/usr/lpp/zosmf/IBM/IZUSPUNE: not 
found
BPXF151I BPXCOPY WAS INVOKED FOR HEAD ID 12.
   
BPXF150I MVS DATA SET WITH DDNAME SYSUT1 SUCCESSFULLY COPIED INTO BINARY HFS 
FILE /SERVICE/usr/lpp/zosmf/IBM/IZUDMUI.  
--- 
   
SHELL SCRIPT IZUDUPUI OUTPUT FOR HFS IZUDMUI SEQ NUM 13 
   

   
/SERVICE/usr/lpp/zosmf/IBM/IZUDUPUI: /SERVICE/usr/lpp/zosmf/IBM/IZUDUPUI: not 
found
BPXF151I BPXCOPY WAS INVOKED FOR HEAD ID 14.
   
BPXF150I MVS DATA SET WITH DDNAME SYSUT1 SUCCESSFULLY COPIED INTO BINARY HFS 
FILE /SERVICE/usr/lpp/zosmf/IBM/IZUGNAEW. 
BPXF140E RETURN CODE 0090, REASON CODE 0549010C.  A LINK FAILED FOR LINK 
NAME /SERVICE/usr/lpp/zosmf/IBM/../lib/izur   
estjobs.jar.
   
BPXF151I BPXCOPY WAS INVOKED FOR HEAD ID 15.
   
BPXF150I MVS DATA SET WITH DDNAME SYSUT1 SUCCESSFULLY COPIED INTO BINARY HFS 
FILE /SERVICE/usr/lpp/zosmf/IBM/IZUCAHLP. 
--- 
   
SHELL SCRIPT IZUCATAR OUTPUT FOR HFS IZUCAHLPSEQ NUM 16 
   

   
/SERVICE/usr/lpp/zosmf/IBM/IZUCATAR: /SERVICE/usr/lpp/zosmf/IBM/IZUCATAR: not 
found

I am unable to determine why the link fails. What did I do wrong?

Regards, 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) - Compilers

[Barbara Nitz]

On Mon, 23 Jul 2018 06:05:43 -0400, John Eells  wrote:

>Over the past few years, COBOL and PL/I have added support for Product
>Registration Services, and can be disabled using IFAPRFxx entries.  XL
>C/C++ is a feature of z/OS and can similarly be enabled or disabled with
>IFAPRDxx.
>
>This does not cover everything, of course, but it's a start.

That wasn't enough for IBM Germany (we had/have that properly set). They 
demanded more than 'just' IFAPRDxx.

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

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

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

[Barbara Nitz]

Ed,

please reread my first post!

>If that's the case, then the fault lies with LE and not BCPii.
How is LE to know that it runs under an implicit sub=mstr? That is not how your 
standard Cobol/PL/I program runs. 
What started this off was our general setting of HEAPCHK(ON) on request of 
application development. It seems that one LE enclave terminates which (with 
HEAPCHK on) wants to write a short 'ceedump' to JES2 spool with the heap 
statistics. When that fails, LE issues a U4087 (I think) and tries an IEATDUMP.

>If the allocation for CEEDUMP fails, then the dump should be taken (for
>example) with IEATDUMP.

*We* have an explicit LE statement DYNDUMP that directs *any* dump to HLQ 
TDUMP. BCPII has *chosen* to overwrite that setting by specifying part of the 
LE Default for DYNDUMP, which is the userid of the address space. STC users are 
not allowed to allocate data sets (RACF audit requirement), hence the general 
HLQ of TDUMP (instead of userid). Which HWIBCPII has overwritten.

Either HWIBCPII is LE-enabled (which I find very questionable for a system 
address space started via OS abracadabra), then it will have to set/override 
*all* options that require JES in one way or another or are otherwise harmful 
and not just a select few that are proudly documented in the books to be 
overwritten if allowed, *or* the address space should NOT be LE-enabled at all. 

Barbara

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

Re: HWIBCPII

[Barbara Nitz]

>> HWIBCPII is one of those magical address spaces that is started by 
>> Abracadabra:
>>
>> S IEESYSAS,PROG=HWIAMIN2
>
>Or by:
>
>S HWISTART (which essentially does the same)

Not quite. S HWISTART waits for JES2 to come up, it does NOT start HWIBCPII 
immediately. (Which is why I tried the sub=mstr that ended in equal disaster).

BCPII is LE-enabled, and the docs proudly point out that they use LE Services 
(and will override whatever an installation has set). Quite obviously IBM has 
never tested a transaction dump *before* JES2 was up. The LE transaction dump 
*requires* JES2, hence HWIBCPII *requires* JES2 (if only in special 
circumstances). Which is why I call this crappy design.

Barbara

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

HWIBCPII

[Barbara Nitz]

We had the (admittedly not so) bright idea to accomate the request from 
application development to activate the HEAPCHK LE Option generally. We did 
this in conjunction with upgrading from 2.1 to 2.3.
As a result, the crappy design of HWIBCPII address space revealed itself. (It 
had been running without problems under 2.1 for quite a while.)
During IPL (and *wy before* JES2 was active) we got these messages:

IEC141I 013-C8,IGG0193K,IEESYSAS,HWIBCPII,CEEDUMP
IEC141I 013-C8,IGG0193K,IEESYSAS,HWIBCPII,SYSOUT 
CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:   
BCPII.D146.T1123091.HWIBCPII 

Why is this thing even coming up when it relies on JES2? Why doesn't it wait 
for JES2?!?

CEA0603I The z/OS Diagnostic Snapshot option failed. 
z/OS component CEA is unavailable for processing this request. 
Diagnostic data will be missing for the following incident with:   
DUMP TITLE: JOBNAME HWIBCPII STEPNAME HWIBCPII  USER  4087 
DATE AND TIME: 05/26/2018 11:23:09 
DUMP DATA SET NAME: BCPII.D146.T1123091.HWIBCPII   
REASON: The CEA address space is unavailable.  

We do NOT run z/OSMF and we do NOT have CEA configured. Which component 
automatically calls CEA and then screams that it is not available?
*Then* insult gets added to injury:

ICH408I USER(BCPII   ) GROUP($STCGRP ) NAME(BCPII   )
  SYS1.MCAT.xx CL(DATASET ) VOL(AWECAT)  
  INSUFFICIENT ACCESS AUTHORITY  
  FROM SYS1.MCAT.xx (G)  
  ACCESS INTENT(UPDATE )  ACCESS ALLOWED(READ   )
IKJ56893I DATA SET BCPII.D146.T1123091.HWIBCPII NOT ALLOCATED+   

Of course not! We do not allow access to the master cat for every Tom, Dick and 
Harry to pollute the master cat with non-defined HLQs. The HLQ BCPII (which is 
equal to the protected STC userid HWIBCPII runs under) does not have an alias 
and is not allowed to allocate data sets. *That's* why the LE Option DYNDUMP 
clearly specifies a general HLQ named TDUMP for each and every transaction dump 
to get allocated under. IBM in their infinite wisdom have choosen to override 
the installation-set DYNDUMP LE Default (that only makes sense for actual TSO 
users, but NOT for LE-enabled STCs, namely to use the userid as HLQ) to enforce 
the IBM default for HLQs. For security reasons, no protected STC is allowed to 
allocate data sets under it's own userid, hence HLQ TDUMP to actually *find* 
all of those transaction  dumps in one place.

IEA820I TRANSACTION DUMP REQUESTED BUT NOT TAKEN 
AUTOMATIC ALLOCATION OF DUMP DATA SET FAILED   
CEE3796I AN ATTEMPT TO DYNAMICALLY TAKE A DUMP WAS NOT SUCCESSFUL. 339 
THE ERROR RETURN CODE WAS 0008 AND THE REASON CODE WAS 0026.   
CEE0374C CONDITION=CEE3250C TOKEN=00040CB2 61C3C5C5 0001 344
 WHILE RUNNING PROGRAM CEEBPCAL WHICH STARTS AT F600
 AT THE TIME OF INTERRUPT   
CEE0374C CONDITION=CEE3250C TOKEN=00040CB2 61C3C5C5 0002 355
 WHILE RUNNING PROGRAM CEEPIPI  
 AT THE TIME OF INTERRUPT   
HWI018I THE BCPII COMMUNICATION RECOVERY HAS DETECTED AN UNEXPECTED 
ERROR. SYSOUT MAY CONTAIN DIAGNOSTICS FOR THIS PROBLEM. 
HWI008I BCPII FAILED TO CONNECT TO THE LOCAL CENTRAL PROCESSOR 367  
COMPLEX (CPC). RC = 0FFF, RSN = . BCPII INITIALIZATION  
IS HALTED.  

When we migrated to 2.3, we didn't have a clue what might be wrong with 
HWIBCPII, so after the system was up and running we just did a "start 
HWISTART". To our utter confusion, *now* it came up without a hitch.

We later found out why setting HEAPCK globally wasn't a good idea and have now 
turned it off again. When we reproduced this on our test system, we did an S 
HWISTART,SUB=MSTR on the assumption that the thing runs sub=mstr when it gets 
started. We got a dump (abend042 with a 'severe internal error' reason code) 
for our pains, so quite obviously it does not work under sub=mstr. Starting it 
under JES, *now* it waits for JES to initialize, probably because something 
global in the system recognizes that JES2 isn't there yet.

There are a number of things wrong here:
1. If HWIBCPII needs JES2 to function (and obviously it does), it just cannot 
do all the shenanigans detailed above and *has to* wait for JES2 to come up. If 
it cannot do that, then it MUST work under the master subsystem. The 
wishy-washy way it behaves now is not acceptable.
2. Since this is an LE-enabled application, it MUST be able to tolerate all and 
any LE options set in an installation. Given that it overrides a number of the 
installation-set LE Options, why doesn't it also override the HEAPCHK option to 
always be off?
3. No STC running with 

Re: ZIIP engine utilization

[Barbara Nitz]

> Can you point me to the best place to see if Ziip is getting maxed out. 

Look at the TYPE70 SMF records. They will show you if the ZIIP is 100% busy.

Regards, 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]

Brian,

>I would think your RASP dump would only be a point in time view of User Key 
>Common at the instant of taking the dump. User Key Common that didn't exist at 
>the time you took the dump wouldn't appear, right?

Completely true. On the other hand: In my experience, user key common (CADS, 
IARV* shared, even Unix shared) has always been set up for long(er) durations, 
so in 99.9% of the cases it should not matter. But those pesky 0.1%!!! 

Barbara

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

Re: Friday Conundrum (aka Soap Box)

[Barbara Nitz]

>Has anyone else gotten frustrated when opened an IBM Service Request in having 
>to select the Operating System, which should have been automatic after 
>selecting the Product and the applicable operating system release level?

Me too. One *always* gets asked what had already been answered. Plus, the boxes 
to choose from are still *way* too small to find things efficiently. I had 
complained about that back when SR first got forced down our collective 
throats. That was at least 8 years ago, and nothing has been changed. I had 
been given a lot of blabla by IBM. I since gave up on even opening SRs unless 
we have a sev1 situation. I'm sure others cannot be bothered to use these 
unreliable, unwieldy tools to report small problems anymore, much to the 
detriment of z/OS. Oh well, I'll survive until retirement!

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]

Replying to several posts:

When I activated OA53355 on my z/OS 2.3 system, I activated that check. It 
tripped immediately and gave me the possibilities (other than what the diag 
trap we've been running with already excluded):
- SCOPE=ALL data space  
- IARVSERV SHARE   
- IARV64 GETSHARED  
- z/OS UNIX shared memory 

Then I did what I always do in these situations: I dumped the RASP address 
space and its data spaces and used IPCS to go hunting (being the impatient sort 
 I didn't want to go the slip route). I used several incantations of IPCS 
RSMDATA, and voila, there was the offender: A common access data space used by 
EMCs GDDR product. None of the other situations seemed to apply to my system. 
Also, DEVMAN and JES2AUX did not show up.

Which brings me to my question: Do I still have to set slip traps or can I be 
sure to have caught everything?

(We were told by EMC that it will take until the next z/OS release until they 
will provide a fix for this.)

Barbara

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

Re: JVM fails to intialize

[Barbara Nitz]

>$ /usr/lpp/java/J8.0_64/bin/java
>-version

Try 
java -Xmcrs2048k -version

My colleague who had figured that out set the specified parm somewhere in USS, 
so now it always works for us just using -version.

Regards, Barbara

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

Re: Software Delivery on Tape to be Discontinued

[Barbara Nitz]

On Mon, 26 Mar 2018 15:23:42 -0400, John Eells  wrote:

>In addition to that, you can take a laptop outside your firewall,
>download stuff*, bring the laptop back in, connect to your internal
>network, and upload it to z/OS to be processed. 

No, you cannot. Where I work, the laptops don't have a DVD/CD drive and are 
essentially just an expensive way of getting to a Citrix client. I cannot even 
reach the internet from my company laptop. All I can access is the company's 
extranet to set up the VPN tunnel. And heaven help you if your anti-virus 
definition isn't current. They update their antivirus catalog and then kick you 
out of VPN in the middle of working because 'definitions are not current'. And 
no USB or Bluetooth, either!
I am one of the lucky few to still have a desktop computer at work which has a 
DVD drive. They made it so that I cannot access that DVD drive anymore, not to 
mention no USB allowed.

We're lucky in that we have been able to set up the sysprog sandplex to access 
the internet for downloads from ShopZ.

Barbara

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

Re: IRRPRMxx

[Barbara Nitz]

Tom,

>The way I read this is that the PARMLIB member does not agree with the
>ICHRDSNT already in use by the RACF sharing group.  Are you absolutely
>sure that the PARMLIB member is correct and agrees with your current
>ICHRDSNT in every respect?  If so, then I would open a PMR for this issue.

thanks for giving me a different interpretation of the message. There was an 
unintended difference in the statistics section. We have reIPL'd, and the 
message is gone. So no sysplex wide IPL necessary! :-)

Barbara

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

Re: IRRPRMxx

[Barbara Nitz]

Tom,

>Your 2.3 system will use the IRRPRMxx member and your 2.1 systems will 
>continue to use the information you specified in the ICHRDSNT load module. All 
>we did was take the information that we specify in the load module and put it 
>in a parmlib member.  We have not had any issues activating this support in a 
>2.1/2.3 sysplex environment.

Are you saying that you did NOT get 
*ICH555A ICHRDSNT FOR MEMBER mem1
 DOES NOT MATCH ICHRDSNT FOR IRRXCF00 GROUP.
 GROUP ICHRDSNT IS USED.
 CORRECT THE PROBLEM AFTER THE IPL TO
 AVOID A FUTURE SYSTEM OUTAGE.
on your 2.3 system? If you did not - we certainly do get it. And the message 
clearly says that there is no ICHRDSNT on my 2.3 system (obviously, since the 
information now comes from a parmlib member). 


Walt,

unfortunately I cannot post to RACF-L from work, and from work I cannot get at 
my private email to establish a password at the list server to post from the 
web interface. (I keep forgetting to do that from my private pc!)

We are currently planning to bring up one system in the 2.1 plex with 2.3, and 
once that works and we corrected all problems, we'll shut down everything and 
re-IPL the 2.3 system first. But it is a nuisance. And so far I haven't seen 
the messages when RACF uses only the parmlib member. I'll see that when we'll 
migrate the first monoplex to 2.3...

Thanks, Barbara

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

IRRPRMxx

[Barbara Nitz]

We are in the process of migrating to z/OS 2.3, and I want to use the new 
IRRPRMxx parmlib member. The documentation in oa52560 is suspiciously silent on 
how to activate this in a sysplex data sharing environment, so I went through 
the RACF books. 

It seems that IRRPRMxx can only be activated with a sysplex wide IPL. Certainly 
it will not be used in a sysplex environment with two systems (when the other 
has toleration but still uses ICHDSNT due to it being 2.1):
*ICH555A ICHRDSNT FOR MEMBER mem1
 DOES NOT MATCH ICHRDSNT FOR IRRXCF00 GROUP. 
 GROUP ICHRDSNT IS USED. 
 CORRECT THE PROBLEM AFTER THE IPL TO
 AVOID A FUTURE SYSTEM OUTAGE.   

Is there a way that I just haven't seen to activate this via rolling IPL? 
(Right out of the box, obviously!)

Barbara

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

Re: Health Check JES_NJE_SECURITY

[Barbara Nitz]

>Ouch. I never saw Walt's proviso mentioned in the doc. Yes, these nodes are 
>all totally under our control. However each node (sysplex) constitutes a 
>different business environment supported by a different RACF data base. A 
>person may have the same userid on sandbox and on production, but they do not 
>necessarily have the same authority on both. Both represent the same person 
>but not necessarily the same role. 
>
>We need to reassess our goal here.

On all of my systems that health check ends with
HZS1002E CHECK(IBMJES,JES_NJE_SECURITY):  
AN ERROR OCCURRED, DIAG: 0300_0004

In the (sysprog) sandplex running mixed with 2.1 and 2.3 we don't get the rc12 
anymore, it has downgraded itself to a rc 4 check on both systems. And we 
haven't done anything to fix anything. NJE isn't even used/active on that 
sysplex even though there are a few definitions in preparation of NJE.

I read the check as having to give those nodes a password (read: certificate) 
somewhere. Which may prove interesting since we have an external NJE node in 
production. Not being very familiar with JES2 or network configuration, I found 
the explanations in the check text fairly incomprehensible. 

Barbara

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