Knowledge Center search link

[Charles Mills]

This will be about the first nice thing I have ever said about KC! I got
into looking at the search option while researching a replacement for
LookAt. I have added this bookmark to my desktop:
https://www.ibm.com/support/knowledgecenter/search/

If you start there you can find things pretty well it seems to me. Here are
the results of some searches that seemed off the top of my head to be
typical of the things I look for:

IEBCOPY - second link found is the main article. Okay, that's an easy one.
STORAGE - Well, that's a tough one. I wanted the macro and it was down about
the twelfth link. STORAGE MACRO did better.
DD - perfect, first link the JCL reference, all of the other links
potentially useful.
strcpy - third link nailed it, but the first two were close enough that they
would probably work (strcpy for AIX and iSeries). Ditto printf.
TCB - I wanted the control block layout and there it was as about the tenth
link
DSAB - Control block layout the first link, with other helpful links for
GETDSAB and XTIOT.
SETPROG - first link nailed it, as did a search for SETPROG APF
START - first "failure" -- I wanted the console command. Got DB2 starts and
so forth. START CONSOLE, START SYSTEM, START COMMAND and START SYSTEM
COMMAND no better. START MVS found it. Not wonderful.
JOB STATEMENT - Bingo, first two links perfect.
LLILF - I wanted the instruction and struck out. Search gave me one link, to
a $HCCT example that uses LLILF. Ditto LHI and TRT. Seems like none of the
opcode mnemonics are searchable. But PRINCIPLES OF OPERATION finds it in the
third link.

You can expand a link right there on the search page so you can see if it is
what you want -- no need to leave the search page and come back.

I'm pretty much sold!

Charles 

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

Re: LOOKAT gone? - Doc Buddy? Seriously!

[Paul Gilmartin]

On Sat, 3 Dec 2016 03:00:15 -0500, David Cole wrote:
>...
>But if the worlds of Apples, PCs, iPhones, and Androids
>has show us anything at all,
>it has shown us that skins matter,
>and that UIs matter.
>
>IBM has a decades long history of releasing unpolished products
>and then polishing them up over the next several releases.
>"Making it pretty" was always an afterthought.
>
But when the coarseness is in a programming interface, the
excuse is too often made, "Polishing it would introduce an
incompatibility with existing art."  The analogy should
be pulling off adhesive tape: the quicker you do it, the better.

>I think that's a mistake that used to be tolerable
>in the closed world of expert customers of decades gone by.
>But even experts want nice things too.
> 
About a half century ago, a programmer could sit down with
a stack of manuals and in a few days learn all that was necessary
about OS/360.  Nowadays, it's essential that things be made
uniform to limit that learning burden.

>I think that "making it pretty" should be
>just as important an objective as "making it work".
>Didn't OS/2 losing the desktop wars of the '90s prove that?
>Didn't Steve Jobs prove that?
> 
And z/OS stands to lose the enterprise war by making a
horrible first impression on talented individuals the
enterprise needs.

A couple weeks ago, Walt Farrell and Peter Relson jumped on
me with a harsh (snarky?) form of "RTFM".  In fact, I had read
it; I merely didn't like what I read.  It said that if the programmer
assigns SYSPRINT or SYSTERM to a UNIX file, the programmer
must specify FILEDATA=TEXT.  Hmmm... What if ...?  I tried it
and learned that if I tried FILEDATA=RECORD (a very new form)
or FILEDATA=BINARY (the default) the operand is ignored and
TEXT is presumed.  No warning message; RC=0.

I think I know the history.  Binder supported the equivalent of
FILEDATA=TEXT before the FILEDATA key existed in JCL or
in allocation.  It's probably the most useful option; in that
sense a wise choice.  When allocation introduced FILEDATA,
BINARY was made the default.  Not outstandingly the best
choice, but I'll be neutral on it.  But to respect the BINARY
default would have introduced a behavioral change; Binder
chose to override.

And another sentence appears in tne Reference; one more thing
for the programmer to memorize.  On the whole, bad!

Walt and Peter both told me:

o If I read all the Binder documentation, I know what I must do.

o IBM is under no obligation to treat a programmer's disobedience
  rationally, nor to to document the consequence of disobedience.

They didn't mention that if I want the behavior of BINARY or
RECORD, I'm SOL.

I'm reminded of the first pages of Hitchhiker.

A couple years ago, I noticed that if I supply Binder SYSLIN
with FILEDATA=TEXT ("RECORD" may not have been an available
option at the time), that was ignored and BINARY (admittedly
the default) is presumed.  This can be a PITA.  It means that I
must pad every record to 80 bytes; newlines have no particular
meaning.

I submitted an RCF (perhaps an SR; I don't recall).  I don't know
if anything changed; I had promptly accommodated.  But I'll
check, and if it still behaves as not documented, I'll submit an SR.
I'd bet on WAD and a DOC APAR.  And the interface becomes more
complex, less polished.  This practice will lead z/OS along the
path of OS/2.

-- gil

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

Re: LOOKAT gone?

[Paul Gilmartin]

On Sat, 3 Dec 2016 11:06:08 -0800, Charles Mills wrote:

>I just tried something this morning. If you go to Knowledge Center search
>https://www.ibm.com/support/knowledgecenter/search/ and type in a message
>number the first hit seems to be the entry in Messages and Codes. Hard to
>see how that is any less satisfactory than LookAt. Better in that it gives
>you additional references also (some of them irrelevant, but who cares).
> 
Ah!  So it's just that the documentation is insufficiently documented.

-- gil

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

Re: LOOKAT gone?

[Charles Mills]

I just tried something this morning. If you go to Knowledge Center search
https://www.ibm.com/support/knowledgecenter/search/ and type in a message
number the first hit seems to be the entry in Messages and Codes. Hard to
see how that is any less satisfactory than LookAt. Better in that it gives
you additional references also (some of them irrelevant, but who cares).

Charles

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

Re: FLASHCOPY QUESTION

[Jesse 1 Robinson]

I don't know of any overt sign of flash copy invocation, but for me there is 
strong circumstantial evidence: lightning fast volume copy. We periodically 
migrate maintenance via full DSS volume copy. Done this for years. Then one 
time the copy job ran in only seconds instead of minutes. I thought for sure 
something had failed. Nope, all was A-OK. It happened that the source and 
target volumes were in the same DS8* DASD subsystem with the flash copy feature 
installed, so (I was told) flash copy got invoked automatically. When we copy 
between DASD subsystems, it still takes minutes. 

BTW I have a narrower view of 'online/offline' than Joel does. I take 'online' 
to be an MVS status involving OS control blocks. A volume is either online or 
offline on that basis. The trouble with bringing in 'reachable' is that it 
introduces a scale of 'accessibility' with many nuances. Is the device 
physically connected at all? If it is connected, is it genned to a chpid? If it 
is genned, is the chpid in the access list for that LPAR? If it is not in the 
list, can the IODF be updated to include it? These questions all cloud the 
issue. So, a volume is either online or offline to the OS at any given moment. 
Duplicate volsers are not allowed to be OS-online concurrently. No other 
restrictions. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joel C. Ewing
Sent: Saturday, December 03, 2016 8:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: FLASHCOPY QUESTION

On 12/03/2016 07:58 AM, esmie moo wrote:
> Gentle Readers,
>
> I have a question about FLASHCOPY using  ADRDSSU and COPY.  In my first 
> example I was told that the job is using FLASHCOPY.  However I do not see any 
> evidence.
>
>  COPY FULL INDYNAM (SDB000) OUTDYNAM (MDB000) DUMPCONDITIONING   
> ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY ' 
>
> >From my understanding it is performing a full volume copy of a source 
> >volume.  If my understanding of the parm DUMPCONDITIONING is correct, it 
> >(DUMPCONDITIONING) allows to make a copy of the source volume and while 
> >keeping the target volume online.
>
> I have done a full volume copy of a source to target without the 
> DUMPCONDITIONING parm and it worked - the volume was fully copied (see 
> below).  Am I missing something? Aren't both examples doing the same thing?   
>  
>
>   COPY  INDDNAME(DASD1) OUTDDNAME(DASD2) -   
>   ALLDATA(*) ALLEXCP COPYVOLID PURGE 
> /*   
>
> However I do not see any evidence of FLASHCOPY being invoked because the FCNC 
> parm is not present.
>
> Here is a my second example:
>
>  COPY FULL IDY(PROM70,3390) ODY(SNAP63,3390) DUMPCOND FCNC- 
> ALLDATA(*) ALLEXCP CANCELERROR PURGE FCTOPPRCPRIMARY - 
> FCSETGTOK(FAILRELATION)   
>
> In the above example FLASCHOPY is being performed because of the FCNC.  
>
> Could you correct my understanding of all 3 examples?
>
> Thanks.
>
>
If you do a full volume copy without DUMPCONDITIONING and with COPYVOLID, that 
means when the copy is complete the target volume will now have the same VOLSER 
as the source volume and dss will force it offline, as you can't have two 
volumes with identical VOLSER online to
the same MVS system.   If your goal was just to make a point-in-time
copy on DASD, that may be sufficient.  But if your goal was to then back up 
that target volume to  removable tape media, you would not be able to do that 
with dss from the same system because the volume is offline because of the 
duplicate VOLSER.  It also means that if you for some reason needed to IPL at 
that point, the system will complain about finding two volumes with the same 
VOLSER and there could be some confusion about which of the two volumes should 
be placed online and the wrong one could be chosen. 

With DUMPCONDITIONING the original different target volume VOLSER is preserved 
so both volumes can be online to the same system and there is no later 
confusion about which is the original and which is the point-in-time copy.  DSS 
is smart enough when restoring from a tape dump of the volume with the 
DUMPCONDITIONING copy to also restore the original VOLSER (this used to require 
either an VTOCINDEX or VVDS dataset on the volume to supply the correct 
VOLSER).  

There are other vendor utilities that will allow one to dump an offline DASD 
volume with a duplicate volser to tape, but this seems to me a perversion of 
the meaning of "offline", which was intended to mean access by the system was 
impossible and that the device could safely be taken physically offline for 
hardware maintenance.

Re: FLASHCOPY QUESTION

[Joel C. Ewing]

On 12/03/2016 07:58 AM, esmie moo wrote:
> Gentle Readers,
>
> I have a question about FLASHCOPY using  ADRDSSU and COPY.  In my first 
> example I was told that the job is using FLASHCOPY.  However I do not see any 
> evidence.
>
>  COPY FULL INDYNAM (SDB000) OUTDYNAM (MDB000) DUMPCONDITIONING   
> ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY ' 
>
> >From my understanding it is performing a full volume copy of a source 
> >volume.  If my understanding of the parm DUMPCONDITIONING is correct, it 
> >(DUMPCONDITIONING) allows to make a copy of the source volume and while 
> >keeping the target volume online.
>
> I have done a full volume copy of a source to target without the 
> DUMPCONDITIONING parm and it worked - the volume was fully copied (see 
> below).  Am I missing something? Aren't both examples doing the same thing?   
>  
>
>   COPY  INDDNAME(DASD1) OUTDDNAME(DASD2) -   
>   ALLDATA(*) ALLEXCP COPYVOLID PURGE 
> /*   
>
> However I do not see any evidence of FLASHCOPY being invoked because the FCNC 
> parm is not present.
>
> Here is a my second example:
>
>  COPY FULL IDY(PROM70,3390) ODY(SNAP63,3390) DUMPCOND FCNC- 
> ALLDATA(*) ALLEXCP CANCELERROR PURGE FCTOPPRCPRIMARY - 
> FCSETGTOK(FAILRELATION)   
>
> In the above example FLASCHOPY is being performed because of the FCNC.  
>
> Could you correct my understanding of all 3 examples?
>
> Thanks.
>
>
If you do a full volume copy without DUMPCONDITIONING and with
COPYVOLID, that means when the copy is complete the target volume will
now have the same VOLSER as the source volume and dss will force it
offline, as you can't have two volumes with identical VOLSER online to
the same MVS system.   If your goal was just to make a point-in-time
copy on DASD, that may be sufficient.  But if your goal was to then back
up that target volume to  removable tape media, you would not be able to
do that with dss from the same system because the volume is offline
because of the duplicate VOLSER.  It also means that if you for some
reason needed to IPL at that point, the system will complain about
finding two volumes with the same VOLSER and there could be some
confusion about which of the two volumes should be placed online and the
wrong one could be chosen. 

With DUMPCONDITIONING the original different target volume VOLSER is
preserved so both volumes can be online to the same system and there is
no later confusion about which is the original and which is the
point-in-time copy.  DSS is smart enough when restoring from a tape dump
of the volume with the DUMPCONDITIONING copy to also restore the
original VOLSER (this used to require either an VTOCINDEX or VVDS
dataset on the volume to supply the correct VOLSER).  

There are other vendor utilities that will allow one to dump an offline
DASD volume with a duplicate volser to tape, but this seems to me a
perversion of the meaning of "offline", which was intended to mean
access by the system was impossible and that the device could safely be
taken physically offline for hardware maintenance.

Assuming there is still a dss FASTREPLICATION parameter, it used to
default to "PREFERRED", which meant if flashcopy wasn't available for
some reason, dss would default to an ordinary copy but still do the COPY
command successfully (just m-u-c-h slower).  If you wanted the copy to
fail if flashcopy were not possible, you had to explicitly request
FASTREPLICATION(REQUIRED).  It should be obvious from the time required
for the COPY command to complete whether flashcopy has been used:  a
fraction of a second for the dss COPY command to complete with fastcopy,
versus minutes without fastcopy.
Joel C. Ewing


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

FLASHCOPY QUESTION

[esmie moo]

Gentle Readers,

I have a question about FLASHCOPY using  ADRDSSU and COPY.  In my first example 
I was told that the job is using FLASHCOPY.  However I do not see any evidence.

 COPY FULL INDYNAM (SDB000) OUTDYNAM (MDB000) DUMPCONDITIONING   
ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY ' 

>From my understanding it is performing a full volume copy of a source volume.  
>If my understanding of the parm DUMPCONDITIONING is correct, it 
>(DUMPCONDITIONING) allows to make a copy of the source volume and while 
>keeping the target volume online.

I have done a full volume copy of a source to target without the 
DUMPCONDITIONING parm and it worked - the volume was fully copied (see below).  
Am I missing something? Aren't both examples doing the same thing?  
  
   
  COPY  INDDNAME(DASD1) OUTDDNAME(DASD2) -   
  ALLDATA(*) ALLEXCP COPYVOLID PURGE 
/*   

However I do not see any evidence of FLASHCOPY being invoked because the FCNC 
parm is not present.

Here is a my second example:

 COPY FULL IDY(PROM70,3390) ODY(SNAP63,3390) DUMPCOND FCNC- 
ALLDATA(*) ALLEXCP CANCELERROR PURGE FCTOPPRCPRIMARY - 
FCSETGTOK(FAILRELATION)   

In the above example FLASCHOPY is being performed because of the FCNC.  

Could you correct my understanding of all 3 examples?

Thanks.

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

Re: JES2 NJE Security

[Walt Farrell]

On Fri, 2 Dec 2016 13:58:40 +, Styles, Andy (SD EP zPlatform) 
 wrote:

>We're trying to put some security in place around JES2 NJE nodes, using the 
>SIGNON=SECURE option (on the NODE statement). We've got it working RACF to 
>RACF, but are having difficulty with a couple of other security managers, 
>where the password stored in RACF doesn't appear to be accepted by the other 
>ESM.
>
>Does anyone else have a mix of security managers, and use SIGNON=SECURE 
>successfully?

Just to be clear, I think you're talking about configuring your NJE signon 
security as described at
  
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/has2a396/5.3.2.6?SHELF=all13be9=20120815121029
or
  http://preview.tinyurl.com/jzbdwax

I don't know if that will work with a mix of RACF and other security products. 
If CA supports the use of APPCLU session keys and you've configured the 
non-RACF systems according to the CA documentation, then I would expect it to 
work. I have no idea, though, whether CA supports that function, nor how it 
would be configured. You might need to contact CA for assistance.

-- 
Walt

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

Re: LOOKAT gone? - Doc Buddy? Seriously?

[David Cole]

[but] Seeing the grandchildren has higher priority on my money.


Absolutely!






At 12/2/2016 09:43 PM, Clark Morris wrote:

On 2 Dec 2016 14:30:01 -0800, in bit.listserv.ibm-main 
dbc...@colesoft.com (David Cole) wrote:

Yep.
But Google does...
If I were willing to spend the dollars to go to an IBM shareholders 
meeting, I would like to embarrass them abut this and the high 
reliability of the service web-site.  Seeing the grandchildren has 
higher priority on my money.

Clark Morris





At 12/2/2016 05:24 PM, Nims,Alva John (Al) wrote:

I guess it does not understand HLA yet.
Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298





-Original Message-

From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Cole
Sent: Friday, December 02, 2016 5:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LOOKAT gone? - Doc Buddy? Seriously?
Thanks for the tip.


Is the ASMA033I message correct? Could it be ASM033I (without the second A)

Yes, ASMA033I is correct. Google it.
ASMAnnnc messages belong to the High Level Assembler.
ASMnc message belong to the "Auxiliary Storage Manager".
Dave





At 12/2/2016 05:01 PM, Nims,Alva John (Al) wrote:
"#3) So once you've figured you need to download the message 
definitions, the next thing you need to know is to which 
component a particular message belongs. Quick... does anybody 
know what IEF540I belongs to? 'Cause apparently I don't. I've 
downloaded a bunch, and while other messages are now findable, 
the IEF messages aren't. (At least not yet.)"

I am doing this with my Android Phone:
In the area where you typed in the "IEF540I" and pressed "GO" you 
will have under the search box "Local | More"  Press the "More" 
side and it will give you the list of message sets that it thinks it is in.
I did the IEF540I after I had already downloaded the z/OS MVS 
1.13 set and it did not find it, but it presented me with the 
z/OS MVS 2.1 & 2.2 options, so I downloaded the 2.2 version and 
it gave me the message info.

Is the ASMA033I message correct? Could it be ASM033I (without the second A)
Al Nims Systems
Admin/Programmer 3
UFIT University of Florida
(352) 273-1298





-Original Message-

From: IBM Mainframe Discussion List
To:IBM-MAIN@LISTSERV.UA.EDU [On Behalf Of David Cole]
Sent: Friday, December 02, 2016 4:43 PM
Subject: Re: LOOKAT gone? - Doc Buddy? Seriously?


There is a phone app called IBM Doc buddy. Try it, you might like it.

Tried it. Don't much like it at all!




Ok, I've just now downloaded and installed Doc Buddy (Android 
version). And the best I can say about it is, whoever designed 
the UI really didn't put much effort into it. I mean seriously, 
doesn't IBM put these things out for real world testing first? 
Then do they even listen to the feedback???
#1) So I installed the app, and of course the very first thing I 
did was type in some message ids. Nothing too esoteric. just 
basic ancient stuff like, I don't know, do you think it'd be 
able to find IEF450I??? Nope... ASMA033I? Nope... Anything? Nope 
nope nopity nope!
#2) It turns out you then have to download... I don't know what 
IBM calls them... I'll just call them "message sets". These are 
organized by component. But there's no mention of this, no 
startup tips, tricks or just general heads-up is put in front of 
you..  Nothing. You install the app, and you're on your own. 
[Pro-tip: Go to the "Component" page.]
#3) So once you've figured you need to download the message 
definitions, the next thing you need to know is to which 
component a particular message belongs. Quick... does anybody 
know what IEF540I belongs to? 'Cause apparently I don't. I've 
downloaded a bunch, and while other messages are now findable, 
the IEF messages aren't. (At least not yet.)
#4) Maybe that message set hasn't downloaded yet. It's hard to 
tell because there is no status display. The individual messages 
sets are hidden in dropdowns that have the very annoying habit 
of going back into hiding on you rather quickly...
#5) And that's another thing. The components list keeps jumping 
around on you because dropdowns that you've opened up 
spontaneously close causing the page to jump up, jump down, jump 
whatever. Come on guys! Can't you stabilize a display long 
enough for somebody to touch a button
#6) Oh and the msgid entry field... So you've got your keyboard 
open and you're typing away, and you decide to clear the entire 
field. But when you do so, Boom! the keyboard disappears on you. Why
#7) Googling a msgid turns out to be just plain easier.  I have 
not tried very many IBM apps, but so far every one I've tried 
feels like it's been written by amateurs! My kid grandson can do 
better than this!





Ok, I've got the IEFxxx messages now. They were where they 
belonged, it just took a long time for the z/OS MVS messages set 
to download.  Good thing I've got a nice fat pipe.
But I still don't have the ASMAxxx messages yet. 

Re: LOOKAT gone? - Doc Buddy? Seriously!

[David Cole]

I will admit...
it is easier to be snarky against something anonymous
such as faceless development teams...
I tend to forget that there are real people
working hard to develop something
other people hopefully will like.

I got an email from one of the UI developers/testers.
Someone I may know.
Not sure, he gave only his first name.
But it did bring home to me
that my criticisms could have been couched in more sympathetic terms.
I owe the team an apology.

Snark is something that comes too easily to me...



I want to like Doc Buddy...
I know that it does achieve its fundamental goal,
and that a lot of good work must have gone into it to make that happen.

But if the worlds of Apples, PCs, iPhones, and Androids
has show us anything at all,
it has shown us that skins matter,
and that UIs matter.



I want to like Doc Buddy...
But it has usability issues
that need to be work before I can do so.

IBM has a decades long history of releasing unpolished products
and then polishing them up over the next several releases.
"Making it pretty" was always an afterthought.

I think that's a mistake that used to be tolerable
in the closed world of expert customers of decades gone by.
But even experts want nice things too.

I think that "making it pretty" should be
just as important an objective as "making it work".
Didn't OS/2 losing the desktop wars of the '90s prove that?
Didn't Steve Jobs prove that?

I do think that I hilighted some significant shortcomings in Doc Buddy.
I do hope that someone will take them into consideration
before the next iteration.

I do regret the snark.
Dave

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