Re: Deleting Alias
On 3.4, remove the / from __ Prefix Dsname Level
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of mf db
Sent: Wednesday, August 21, 2013 6:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Deleting Alias
Hello,
I was able to delete a alias from a usercatalog with a below parms :
DEL ENTRYNAME ALIAS CAT(USERCAT)
Defining alias to a Non Vsam :
DEF ALIAS (NAME(XX..)-
RELATE('X..ZZZ.'))
But when I tried checking the alias with ISPF 3.4 option I couldn't see the
entry being visible.
When I do listcat against the dataset ..ZZZ. but I could see the
alias relation for XXX... Not sure why the alias entry is not visible.
I tried even deleting and defining back but no luck. I do get a message as
duplicate dataset name when I try defining it again.
IDC3013I DUPLICATE DATA SET NAME
Z/OS : 1.13
Could some please shed some light on the above.
/Peter
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Its already removed...
On Wed, Aug 21, 2013 at 4:34 PM, Richards, Robert B.
robert.richa...@opm.gov wrote:
On 3.4, remove the / from __ Prefix Dsname Level
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of mf db
Sent: Wednesday, August 21, 2013 6:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Deleting Alias
Hello,
I was able to delete a alias from a usercatalog with a below parms :
DEL ENTRYNAME ALIAS CAT(USERCAT)
Defining alias to a Non Vsam :
DEF ALIAS (NAME(XX..)-
RELATE('X..ZZZ.'))
But when I tried checking the alias with ISPF 3.4 option I couldn't see
the entry being visible.
When I do listcat against the dataset ..ZZZ. but I could see
the alias relation for XXX... Not sure why the alias entry is not
visible.
I tried even deleting and defining back but no luck. I do get a message as
duplicate dataset name when I try defining it again.
IDC3013I DUPLICATE DATA SET NAME
Z/OS : 1.13
Could some please shed some light on the above.
/Peter
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Continuation (Was Coptying Unix Files)
I _hate_ BPXBATCH. I can't use DD * for its input. Sucks branch water. What I wish I could do would be: //RUNUNIX EXEC PGM=BPXBATCH,PARM='SH /bin/sh -L' //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //STDIN DD * cmd1 cmd2 cmd3 parm1 |\ cmd4 #reading stdout of cmd3 above /* // No can do. But I can do this with OSHELL. If I just need a single long command, then using //STDPARM DD * does work. But I rarely need something that simple. Which is why I use Co:Z Batch On Tue, Aug 20, 2013 at 10:24 PM, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In caajsdjibrlzzptbo+1evl8uidygxt4mgnunbo954o2rpuxj...@mail.gmail.com, on 08/20/2013 at 09:10 AM, John McKown john.archie.mck...@gmail.com said: And I often use OSHELL examples here simply because many shops are restricted from installing unapproved software. BPXBATCH. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Man Pages for Ported Tools?
What is really amusing to me is that when I browsed it, it looked very
similar to an old style BookManager data set. So I looked at the DCB
characteristics of one of my existing BookManager MVS manuals. It is
FBS/4096/4096. I then created an empty data set with those characteristics,
and did a binary copy (cp -B) of the hpuza200.book file into it. Guess
what? I could then open it in ISPF BookManager READ!
BookManager is alive and well and living in z/OS UNIX!
On Tue, Aug 20, 2013 at 3:57 PM, Paul Gilmartin paulgboul...@aim.comwrote:
On Tue, 20 Aug 2013 11:16:35 -0500, John McKown wrote:
export MANPATH=${MANPATH}:/usr/lpp/ported/man/%L
Works for me, too. Thanks.
Fairly Mysterious; I see:
SPPG@MVS3:134$ ( cd /usr/lpp/ported/man amp; find . -ls )
241 drwxr-xr-x 3 SSSV OMVS 288 Oct 2 2011 .
251 drwxr-xr-x 3 SSSV OMVS 288 Oct 2 2011 ./C
261 drwxr-xr-x 2 SSSV OMVS 288 Oct 2 2011 ./C/man1
27 324 -rw-r--r-- 2 SSSV OMVS 655360 Oct 2 2011
./C/man1/hpuza200.book
How dey do dat? Is the big thing some sorta archive?
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
As of next week, passwords will be entered in Morse code.
Maranatha!
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Continuation (Was Coptying Unix Files)
Howdy, I use this which works quite well, //SHELL EXEC PGM=BPXBATCH,REGION=8M //STDIN DD DUMMY //STDOUT DD DUMMY //STDERR DD PATH='/u/sdda###/Logs/shell.error', // PATHOPTS=(OWRONLY,OCREAT,OTRUNC), // PATHMODE=SIRWXU //*** //* Enter shell commands below, only need * //* SH on the first line, separate commands * //* with an ';' * //*** //STDPARM DD * SH first command ; second command ; third command ; last command Regards, Neil Haley nha...@ca.ibm.com Storage Software Mainframe Support http://www.ibm.com/systems/z/ | http://www.about.me/NeilHaley From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@listserv.ua.edu, Date: 08/21/2013 08:20 Subject:Re: USS Continuation (Was Coptying Unix Files) Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu I _hate_ BPXBATCH. I can't use DD * for its input. Sucks branch water. What I wish I could do would be: //RUNUNIX EXEC PGM=BPXBATCH,PARM='SH /bin/sh -L' //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //STDIN DD * cmd1 cmd2 cmd3 parm1 |\ cmd4 #reading stdout of cmd3 above /* // No can do. But I can do this with OSHELL. If I just need a single long command, then using //STDPARM DD * does work. But I rarely need something that simple. Which is why I use Co:Z Batch On Tue, Aug 20, 2013 at 10:24 PM, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In caajsdjibrlzzptbo+1evl8uidygxt4mgnunbo954o2rpuxj...@mail.gmail.com, on 08/20/2013 at 09:10 AM, John McKown john.archie.mck...@gmail.com said: And I often use OSHELL examples here simply because many shops are restricted from installing unapproved software. BPXBATCH. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Continuation (Was Coptying Unix Files)
Neil, Some would disagree that this works well at all, and prefer - - normal shell input conventions (not one line) - running the shell in the same address space - better accounting - can one of your commands use a DD in the job step??? - STDOUT and STDERR output to spool (although BPXBATCH since 1.7 supports that) On Wed, Aug 21, 2013 at 8:34 AM, Neil Haley nha...@ca.ibm.com wrote: Howdy, I use this which works quite well, //SHELL EXEC PGM=BPXBATCH,REGION=8M //STDIN DD DUMMY //STDOUT DD DUMMY //STDERR DD PATH='/u/sdda###/Logs/shell.error', // PATHOPTS=(OWRONLY,OCREAT,OTRUNC), // PATHMODE=SIRWXU //*** //* Enter shell commands below, only need * //* SH on the first line, separate commands * //* with an ';' * //*** //STDPARM DD * SH first command ; second command ; third command ; last command -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Continuation (Was Coptying Unix Files)
Okay. We have used copytree for a while. It comes in the sample directory in USS. No one has mentioned that. Thanks. John Eatherly -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Continuation (Was Coptying Unix Files)
Kirk Wolf wrote: - better accounting Hmm, I'm not with you, perhaps I'm blond, but... :-D Could you be very kind to elaborate on this phrase: 'better accounting' ? TAI! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
On Wed, 21 Aug 2013 11:25:36 +, Tidy, David (D) wrote: The alias will be created in the same catalog as the related object Are you sure? The AMS manual doesn't say that, as far as I can see. In any case, unless both the alias and the data set name resolve to the same user catalog, the alias is worthless. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Continuation (Was Coptying Unix Files)
On Wed, 21 Aug 2013 09:34:55 -0400, Neil Haley nha...@ca.ibm.com wrote: ... //*** //* Enter shell commands below, only need * //* SH on the first line, separate commands * //* with an ';' * //*** //STDPARM DD * SH first command ; second command ; third command ; last command ... which suffers the unfortunate restriction that you can't employ symbol substitution in STDPARM. (It will be better in 2.1.) It's regrettable that designers chose to make STDPARM override the EXEC PARM= string rather than appending to it; otherwise one could start with 99 characters of shell variable definitions using JCL symbol substitution. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
On Wed, 21 Aug 2013 09:07:51 -0500, Tom Marchant wrote: In any case, unless both the alias and the data set name resolve to the same user catalog, the alias is worthless. That is one of the dumber design decisions I have ever encountered. Simply, alias resolution should search for the RELATED DSN in the catalog corresponding to its HLQ where it is, not that of the alias. Multi-level aliasing would be nice, too. And why is an alias of a VSAM DSN called something else (PATH, IIRC) rather than simply ALIAS? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Lizette,
The LISTCAT shows that both the values are pointing to the same usercatalog.
On Wed, Aug 21, 2013 at 7:47 PM, Lizette Koehler stars...@mindspring.comwrote:
Note in the definition of the DEF ALIAS RELATE() it states: The
resolved value for entryname must be a catalog entry that is located in the
same catalog that contains the value for aliasname.
So you need to ensure the RELATE entryname is in the same catalog as the
main entry name.
So if your entryname is BOB.MY.FILE that is in ucat MYUCAT1 then when you
do the
DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED hlq
must be in MYUCAT1
I may have that backwards, but it is close. Bottom line, the example IBM
has in the book for doing this is very bad. I will be opening a request for
updating that to a more reasonable example. Second, from the document it
appears that the HLQs should be in the same UCAT. At least that is my
understanding from reading the IBM doc (which is very nebulous at best).
And I do not believe that you are required to use the CAT parameter in the
DEF ... ALIAS RELATE() function
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of mf db
Sent: Wednesday, August 21, 2013 3:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Deleting Alias
Hello,
I was able to delete a alias from a usercatalog with a below parms :
DEL ENTRYNAME ALIAS CAT(USERCAT)
Defining alias to a Non Vsam :
DEF ALIAS (NAME(XX..)-
RELATE('X..ZZZ.'))
But when I tried checking the alias with ISPF 3.4 option I couldn't see the
entry being visible.
When I do listcat against the dataset ..ZZZ. but I could see
the
alias relation for XXX... Not sure why the alias entry is not
visible.
I tried even deleting and defining back but no luck. I do get a message as
duplicate dataset name when I try defining it again.
IDC3013I DUPLICATE DATA SET NAME
Z/OS : 1.13
Could some please shed some light on the above.
/Peter
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Continuation (Was Coptying Unix Files)
Nice! Thanks for that I hadn't thought of it. On Wed, Aug 21, 2013 at 8:34 AM, Neil Haley nha...@ca.ibm.com wrote: Howdy, I use this which works quite well, //SHELL EXEC PGM=BPXBATCH,REGION=8M //STDIN DD DUMMY //STDOUT DD DUMMY //STDERR DD PATH='/u/sdda###/Logs/shell.error', // PATHOPTS=(OWRONLY,OCREAT,OTRUNC), // PATHMODE=SIRWXU //*** //* Enter shell commands below, only need * //* SH on the first line, separate commands * //* with an ';' * //*** //STDPARM DD * SH first command ; second command ; third command ; last command Regards, Neil Haley nha...@ca.ibm.com Storage Software Mainframe Support http://www.ibm.com/systems/z/ | http://www.about.me/NeilHaley From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@listserv.ua.edu, Date: 08/21/2013 08:20 Subject:Re: USS Continuation (Was Coptying Unix Files) Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu I _hate_ BPXBATCH. I can't use DD * for its input. Sucks branch water. What I wish I could do would be: //RUNUNIX EXEC PGM=BPXBATCH,PARM='SH /bin/sh -L' //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //STDIN DD * cmd1 cmd2 cmd3 parm1 |\ cmd4 #reading stdout of cmd3 above /* // No can do. But I can do this with OSHELL. If I just need a single long command, then using //STDPARM DD * does work. But I rarely need something that simple. Which is why I use Co:Z Batch On Tue, Aug 20, 2013 at 10:24 PM, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In caajsdjibrlzzptbo+1evl8uidygxt4mgnunbo954o2rpuxj...@mail.gmail.com, on 08/20/2013 at 09:10 AM, John McKown john.archie.mck...@gmail.com said: And I often use OSHELL examples here simply because many shops are restricted from installing unapproved software. BPXBATCH. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Continuation (Was Coptying Unix Files)
On Wed, Aug 21, 2013 at 8:59 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Kirk Wolf wrote: - better accounting Hmm, I'm not with you, perhaps I'm blond, but... :-D Could you be very kind to elaborate on this phrase: 'better accounting' ? Forked OMVS address spaces are a different WLM class; resource usage is not accounted for in the main JES2 address space. Of course, even if the shell runs in the original JES2 address space (like BPXBATSL) and you set BPX_SHAREAS=YES and BPX_SPAWN_SCRIPT=YES, you can still do things that fork into OMVS address spaces. But many things can be run in the original address space and accounted for there. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
mf db wrote:
n ISPF 3.4, put in the '/' on the line for include additional qualifiers
It is there...
Then you have messy problems. What is your TSO PREFIX setting?
I was able to delete a alias from a usercatalog with a below parms :
DEL ENTRYNAME ALIAS CAT(USERCAT)
Did you do a LISTC before deletion?
Defining alias to a Non Vsam :
DEF ALIAS (NAME(XX..)-
RELATE('X..ZZZ.'))
Then, did you do a LISTC on that? The catalog itself, the entry itself and the
related catalog.
But when I tried checking the alias with ISPF 3.4 option I couldn't see the
entry being visible.
You have a problem with your catalog search order. Check from Master Catalog
all the way down to that user catalog for pointers. You can try =3.4 using XX,
then XX., and so on. if you can see something, press PF10-PF11 until you
see the catalog.
I think you have duplicate entries or your master catalog is not pointing to
the right user catalog.
I tried even deleting and defining back but no luck. I do get a message as
duplicate dataset name when I try defining it again.
If it is a duplicate, then use ISMF and using the name and the catalog names to
search where is that entry is actually.
Or it is somewhere on a volume. If it is in a SMS volser, but not cataloged,
then you need other remedies for that.
I think you should post the results of your searches so the right approach can
be recommended to fix it. Of course, make a backup of your catalogs first.
Groete / Greetings
Elardus Engelbrecht
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
I am sure in that we had exactly this issue recently when someone tried to alias non-vsam dataset across catalogs. I thought I found something somewhere that logically (but not necessarily explicitly) supported this statement, but it might take me some time to find back again. Best regards, David Tidy Tel:(31)115-67-1745 IS Technical Management/SAP-Mf Dow Benelux B.V. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: 21 August 2013 16:08 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Deleting Alias On Wed, 21 Aug 2013 11:25:36 +, Tidy, David (D) wrote: The alias will be created in the same catalog as the related object Are you sure? The AMS manual doesn't say that, as far as I can see. In any case, unless both the alias and the data set name resolve to the same user catalog, the alias is worthless. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Do you have multilevel alias implemented in your environment?
If so, you may have TED and BOB in one catalog but perhaps TED.MY and BOB.MY
are in different catalogs???
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of mf db
Sent: Wednesday, August 21, 2013 7:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Deleting Alias
Lizette,
The LISTCAT shows that both the values are pointing to the same usercatalog.
On Wed, Aug 21, 2013 at 7:47 PM, Lizette Koehler
stars...@mindspring.comwrote:
Note in the definition of the DEF ALIAS RELATE() it states:
The resolved value for entryname must be a catalog entry that is
located in the same catalog that contains the value for aliasname.
So you need to ensure the RELATE entryname is in the same catalog as
the main entry name.
So if your entryname is BOB.MY.FILE that is in ucat MYUCAT1 then when
you do the
DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED
hlq must be in MYUCAT1
I may have that backwards, but it is close. Bottom line, the example
IBM has in the book for doing this is very bad. I will be opening a
request for updating that to a more reasonable example. Second, from
the document it appears that the HLQs should be in the same UCAT. At
least that is my understanding from reading the IBM doc (which is very
nebulous at best).
And I do not believe that you are required to use the CAT parameter in
the DEF ... ALIAS RELATE() function
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of mf db
Sent: Wednesday, August 21, 2013 3:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Deleting Alias
Hello,
I was able to delete a alias from a usercatalog with a below parms :
DEL ENTRYNAME ALIAS CAT(USERCAT)
Defining alias to a Non Vsam :
DEF ALIAS (NAME(XX..)-
RELATE('X..ZZZ.'))
But when I tried checking the alias with ISPF 3.4 option I couldn't
see the entry being visible.
When I do listcat against the dataset ..ZZZ. but I could
see the alias relation for XXX... Not sure why the alias entry
is not visible.
I tried even deleting and defining back but no luck. I do get a
message as duplicate dataset name when I try defining it again.
IDC3013I DUPLICATE DATA SET NAME
Z/OS : 1.13
Could some please shed some light on the above.
/Peter
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Continuation (Was Coptying Unix Files)
Kirk Wolf wrote: Forked OMVS address spaces are a different WLM class; resource usage is not accounted for in the main JES2 address space. Of course, even if the shell runs in the original JES2 address space (like BPXBATSL) and you set BPX_SHAREAS=YES and BPX_SPAWN_SCRIPT=YES, you can still do things that fork into OMVS address spaces. But many things can be run in the original address space and accounted for there. Thanks. It is in this sense, I now understand what you means by 'accounting'. Cool answer! Thanks again, much appreciated! :-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote: DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED hlq must be in MYUCAT1 You can control which catalog the TED alias is created in, but if the catalogs are different you lose either way. If you create TED in BOB's catalog, catalog search fails to find TED; if you create TED in its proper catalog, catalog search fails to find BOB. I may have that backwards, but it is close. Bottom line, the example IBM has in the book for doing this is very bad. I will be opening a request for updating that to a more reasonable example.... Rather, that should be a Requirement that it be done right, not a RCF for documentation that it is done wrong. ... Second, from the document it appears that the HLQs should be in the same UCAT. At least that is my understanding from reading the IBM doc (which is very nebulous at best). And I do not believe that you are required to use the CAT parameter in the DEF ... ALIAS RELATE() function -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Aliases are most useful for PDS and PDSE members, and they are handled very differently in the two. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Elardus, I tried viewing via ISMF and I could see the alias entry pointing the same usercatalog, but when I type Browse agains the alias I get a message as Dataset not catalogued On Wed, Aug 21, 2013 at 8:01 PM, Paul Gilmartin paulgboul...@aim.comwrote: On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote: DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED hlq must be in MYUCAT1 You can control which catalog the TED alias is created in, but if the catalogs are different you lose either way. If you create TED in BOB's catalog, catalog search fails to find TED; if you create TED in its proper catalog, catalog search fails to find BOB. I may have that backwards, but it is close. Bottom line, the example IBM has in the book for doing this is very bad. I will be opening a request for updating that to a more reasonable example.... Rather, that should be a Requirement that it be done right, not a RCF for documentation that it is done wrong. ... Second, from the document it appears that the HLQs should be in the same UCAT. At least that is my understanding from reading the IBM doc (which is very nebulous at best). And I do not believe that you are required to use the CAT parameter in the DEF ... ALIAS RELATE() function -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
In 3.4 if you display the dataset and then PF11 - see if there are dataset attributes. If there is no space, no lrecl, no blksize, and so forth, then all you have is a catalog entry and that is it. You can create as many catalog entries as you like that do not have REAL datasets underneath them. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db Sent: Wednesday, August 21, 2013 7:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Deleting Alias Elardus, I tried viewing via ISMF and I could see the alias entry pointing the same usercatalog, but when I type Browse agains the alias I get a message as Dataset not catalogued On Wed, Aug 21, 2013 at 8:01 PM, Paul Gilmartin paulgboul...@aim.comwrote: On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote: DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED hlq must be in MYUCAT1 You can control which catalog the TED alias is created in, but if the catalogs are different you lose either way. If you create TED in BOB's catalog, catalog search fails to find TED; if you create TED in its proper catalog, catalog search fails to find BOB. I may have that backwards, but it is close. Bottom line, the example IBM has in the book for doing this is very bad. I will be opening a request for updating that to a more reasonable example.... Rather, that should be a Requirement that it be done right, not a RCF for documentation that it is done wrong. ... Second, from the document it appears that the HLQs should be in the same UCAT. At least that is my understanding from reading the IBM doc (which is very nebulous at best). And I do not believe that you are required to use the CAT parameter in the DEF ... ALIAS RELATE() function -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Lizette, But I am not able to create and relate with same alias and I get a duplicate dataset entry. Here the background is that I am trying to use this alias in one of our proclibs. On Wed, Aug 21, 2013 at 8:12 PM, Lizette Koehler stars...@mindspring.comwrote: In 3.4 if you display the dataset and then PF11 - see if there are dataset attributes. If there is no space, no lrecl, no blksize, and so forth, then all you have is a catalog entry and that is it. You can create as many catalog entries as you like that do not have REAL datasets underneath them. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db Sent: Wednesday, August 21, 2013 7:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Deleting Alias Elardus, I tried viewing via ISMF and I could see the alias entry pointing the same usercatalog, but when I type Browse agains the alias I get a message as Dataset not catalogued On Wed, Aug 21, 2013 at 8:01 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote: DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED hlq must be in MYUCAT1 You can control which catalog the TED alias is created in, but if the catalogs are different you lose either way. If you create TED in BOB's catalog, catalog search fails to find TED; if you create TED in its proper catalog, catalog search fails to find BOB. I may have that backwards, but it is close. Bottom line, the example IBM has in the book for doing this is very bad. I will be opening a request for updating that to a more reasonable example.... Rather, that should be a Requirement that it be done right, not a RCF for documentation that it is done wrong. ... Second, from the document it appears that the HLQs should be in the same UCAT. At least that is my understanding from reading the IBM doc (which is very nebulous at best). And I do not believe that you are required to use the CAT parameter in the DEF ... ALIAS RELATE() function -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Man Pages for Ported Tools?
On 8/21/2013 at 08:38 AM, John McKown john.archie.mck...@gmail.com wrote: I then created an empty data set with those characteristics, and did a binary copy (cp -B) of the hpuza200.book file into it. Guess what? I could then open it in ISPF BookManager READ! BookManager is alive and well and living in z/OS UNIX! Given the name of the file is hpuza200.book, did you really think you had to go to all that trouble? :) Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
This problem seems unclear because of the two catalog ALIAS uses. One for the
HLQ that probably points to a user catlg and another for the DSN alias pointing
to a user catlg. Ensure that both are pointing to the same catalog. Is there
an ALIAS entry for the HLQ?
Cliff McNeill
I was able to delete a alias from a usercatalog with a below parms :
DEL ENTRYNAME ALIAS CAT(USERCAT)
Defining alias to a Non Vsam :
DEF ALIAS (NAME(XX..)-
RELATE('X..ZZZ.'))
But when I tried checking the alias with ISPF 3.4 option I couldn't see the
entry being visible.
When I do listcat against the dataset ..ZZZ. but I could see
the alias relation for XXX... Not sure why the alias entry is not
visible.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Catalog aliases (as opposed to PDS member aliases) have two different
uses.
1. By far the most common is high-level-qualifier such as TSO userid. In
this case, the alias itself lives in the master catalog and
points--RELATEs--to a user catalog that contains one or more actual DSNs
that all begin with the HLQ. To delete such an alias, you *must not* name
the user catalog in the command because user cat name is just part of the
entry you are deleting. You are deleting the alias (implicitly) from the
master catalog.
DEL 'hlq' ALIAS
2. A less common usage but one we deploy to manage ServerPac data sets
relates a fully qualified DSN in a user catalog to a different name. For
example:
'OSR13.SYS1.LINKILIB' is defined in 'MVSR13.ICF.MASTER' as
pointing--RELATing--to 'SYS1.LINKLIB' on the SMPE target volume. In order
for this to work, there must still be an HLQ alias 'OSR13'
pointing--RELATing--to the user catalog as in (1). To delete the fully
qualified alias data set name from the user catalog, you must name the
user catalog because that's where the alias entry actually lives.
DEL 'fully-qualified-name' ALIAS CAT('usercat-name') NOSCRATCH
I threw in NOSCRATCH because otherwise your actual data set will
disappear. Unless that's what you want.
3. If you are getting 'duplicate name' when you try to redefine the alias,
then you did not actually delete the alias in the first place. That would
be the result of including user cat name in the command in (1) above. The
command would fail, and the alias would remain in the master catalog.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: mf db dbajava...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 08/21/2013 07:40 AM
Subject:Re: Deleting Alias
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Elardus,
I tried viewing via ISMF and I could see the alias entry pointing the same
usercatalog, but when I type Browse agains the alias I get a message as
Dataset not catalogued
On Wed, Aug 21, 2013 at 8:01 PM, Paul Gilmartin
paulgboul...@aim.comwrote:
On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote:
DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED
hlq
must be in MYUCAT1
You can control which catalog the TED alias is created in, but if the
catalogs are different you lose either way. If you create TED in
BOB's catalog, catalog search fails to find TED; if you create TED
in its proper catalog, catalog search fails to find BOB.
I may have that backwards, but it is close. Bottom line, the example
IBM
has in the book for doing this is very bad. I will be opening a request
for
updating that to a more reasonable example....
Rather, that should be a Requirement that it be done right, not
a RCF for documentation that it is done wrong.
... Second, from the document it
appears that the HLQs should be in the same UCAT. At least that is my
understanding from reading the IBM doc (which is very nebulous at
best).
And I do not believe that you are required to use the CAT parameter in
the
DEF ... ALIAS RELATE() function
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
On Wed, 21 Aug 2013 20:25:48 +0530, mf db wrote: But I am not able to create and relate with same alias and I get a duplicate dataset entry. Here the background is that I am trying to use this alias in one of our proclibs. If the alias has the same name as the related data set, it would seem that the alias is unnecessary. On Wed, Aug 21, 2013 at 8:12 PM, Lizette Koehler wrote: In 3.4 if you display the dataset and then PF11 - see if there are dataset attributes. If there is no space, no lrecl, no blksize, and so forth, then all you have is a catalog entry and that is it. You can create as many catalog entries as you like that do not have REAL datasets underneath them. But you can't create an alias unless the RELATEd DSN is catalogued. Unless you call it a SYMBOLIC alias, and you can't create a SYMBOLIC alias unless its name contains one or more actual symbols. Silly rule. On Wed, 21 Aug 2013 10:39:41 -0400, John Gilmore wrote: Aliases are most useful for PDS and PDSE members, and they are handled very differently in the two. And both are even more radically different from catalogued aliases of data set names. Hmmm... If a directory alias exists for a PDS (or PDSE) member, and I EDIT and SAVE that member, what's the subsequent condition of the alias? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
The NOSCRATCH does not takes up :
DEL .linklib ALIAS CATALOG(ICF.UCAT.CAT2) NOSCRATCH
IDC3226I INCONSISTENT PARAMETERS INVOLVING 'NOSCRATCH'
On Wed, Aug 21, 2013 at 8:41 PM, Skip Robinson jo.skip.robin...@sce.comwrote:
Catalog aliases (as opposed to PDS member aliases) have two different
uses.
1. By far the most common is high-level-qualifier such as TSO userid. In
this case, the alias itself lives in the master catalog and
points--RELATEs--to a user catalog that contains one or more actual DSNs
that all begin with the HLQ. To delete such an alias, you *must not* name
the user catalog in the command because user cat name is just part of the
entry you are deleting. You are deleting the alias (implicitly) from the
master catalog.
DEL 'hlq' ALIAS
2. A less common usage but one we deploy to manage ServerPac data sets
relates a fully qualified DSN in a user catalog to a different name. For
example:
'OSR13.SYS1.LINKILIB' is defined in 'MVSR13.ICF.MASTER' as
pointing--RELATing--to 'SYS1.LINKLIB' on the SMPE target volume. In order
for this to work, there must still be an HLQ alias 'OSR13'
pointing--RELATing--to the user catalog as in (1). To delete the fully
qualified alias data set name from the user catalog, you must name the
user catalog because that's where the alias entry actually lives.
DEL 'fully-qualified-name' ALIAS CAT('usercat-name') NOSCRATCH
I threw in NOSCRATCH because otherwise your actual data set will
disappear. Unless that's what you want.
3. If you are getting 'duplicate name' when you try to redefine the alias,
then you did not actually delete the alias in the first place. That would
be the result of including user cat name in the command in (1) above. The
command would fail, and the alias would remain in the master catalog.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: mf db dbajava...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 08/21/2013 07:40 AM
Subject:Re: Deleting Alias
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Elardus,
I tried viewing via ISMF and I could see the alias entry pointing the same
usercatalog, but when I type Browse agains the alias I get a message as
Dataset not catalogued
On Wed, Aug 21, 2013 at 8:01 PM, Paul Gilmartin
paulgboul...@aim.comwrote:
On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote:
DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED
hlq
must be in MYUCAT1
You can control which catalog the TED alias is created in, but if the
catalogs are different you lose either way. If you create TED in
BOB's catalog, catalog search fails to find TED; if you create TED
in its proper catalog, catalog search fails to find BOB.
I may have that backwards, but it is close. Bottom line, the example
IBM
has in the book for doing this is very bad. I will be opening a request
for
updating that to a more reasonable example....
Rather, that should be a Requirement that it be done right, not
a RCF for documentation that it is done wrong.
... Second, from the document it
appears that the HLQs should be in the same UCAT. At least that is my
understanding from reading the IBM doc (which is very nebulous at
best).
And I do not believe that you are required to use the CAT parameter in
the
DEF ... ALIAS RELATE() function
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Sorry about that. NSCR is valid only for DEL NONVSAM. Not for alias. Leave
out that operand. No ill consequences.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: mf db dbajava...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 08/21/2013 08:26 AM
Subject:Re: Deleting Alias
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
The NOSCRATCH does not takes up :
DEL .linklib ALIAS CATALOG(ICF.UCAT.CAT2) NOSCRATCH
IDC3226I INCONSISTENT PARAMETERS INVOLVING 'NOSCRATCH'
On Wed, Aug 21, 2013 at 8:41 PM, Skip Robinson
jo.skip.robin...@sce.comwrote:
Catalog aliases (as opposed to PDS member aliases) have two different
uses.
1. By far the most common is high-level-qualifier such as TSO userid. In
this case, the alias itself lives in the master catalog and
points--RELATEs--to a user catalog that contains one or more actual DSNs
that all begin with the HLQ. To delete such an alias, you *must not*
name
the user catalog in the command because user cat name is just part of
the
entry you are deleting. You are deleting the alias (implicitly) from the
master catalog.
DEL 'hlq' ALIAS
2. A less common usage but one we deploy to manage ServerPac data sets
relates a fully qualified DSN in a user catalog to a different name. For
example:
'OSR13.SYS1.LINKILIB' is defined in 'MVSR13.ICF.MASTER' as
pointing--RELATing--to 'SYS1.LINKLIB' on the SMPE target volume. In
order
for this to work, there must still be an HLQ alias 'OSR13'
pointing--RELATing--to the user catalog as in (1). To delete the fully
qualified alias data set name from the user catalog, you must name the
user catalog because that's where the alias entry actually lives.
DEL 'fully-qualified-name' ALIAS CAT('usercat-name') NOSCRATCH
I threw in NOSCRATCH because otherwise your actual data set will
disappear. Unless that's what you want.
3. If you are getting 'duplicate name' when you try to redefine the
alias,
then you did not actually delete the alias in the first place. That
would
be the result of including user cat name in the command in (1) above.
The
command would fail, and the alias would remain in the master catalog.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: mf db dbajava...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 08/21/2013 07:40 AM
Subject:Re: Deleting Alias
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Elardus,
I tried viewing via ISMF and I could see the alias entry pointing the
same
usercatalog, but when I type Browse agains the alias I get a message as
Dataset not catalogued
On Wed, Aug 21, 2013 at 8:01 PM, Paul Gilmartin
paulgboul...@aim.comwrote:
On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote:
DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED
hlq
must be in MYUCAT1
You can control which catalog the TED alias is created in, but if the
catalogs are different you lose either way. If you create TED in
BOB's catalog, catalog search fails to find TED; if you create TED
in its proper catalog, catalog search fails to find BOB.
I may have that backwards, but it is close. Bottom line, the example
IBM
has in the book for doing this is very bad. I will be opening a
request
for
updating that to a more reasonable example....
Rather, that should be a Requirement that it be done right, not
a RCF for documentation that it is done wrong.
... Second, from the document it
appears that the HLQs should be in the same UCAT. At least that is
my
understanding from reading the IBM doc (which is very nebulous at
best).
And I do not believe that you are required to use the CAT parameter
in
the
DEF ... ALIAS RELATE() function
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Then you may have a aparable condition. I would open a case (SR) with IBM and see if they have any open APARs on this condition Personally I go to ISPF 3.4 and bring up the file name I want to delete Then issue Del / alias And hit enter Or Del / alias noscratch Note I do not use the catalog parameter. Catalog should know where to go. If you are working in a production environment. Be very careful you do not create a recovery situation for yourself. I always do this on my sandbox until I am sure of the command sequences. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db Sent: Wednesday, August 21, 2013 8:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Deleting Alias The NOSCRATCH does not takes up : DEL .linklib ALIAS CATALOG(ICF.UCAT.CAT2) NOSCRATCH IDC3226I INCONSISTENT PARAMETERS INVOLVING 'NOSCRATCH' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JES2 EXIT 40 ASMA90 Parm Question
CROSS-POSTED to ASSEMBLER-LIST and IBM-MAIN Dear Group, I worked with IBM to determine the best way to move print from one JES2 spool to another was by using EXIT 40. Last time I was assembling a CSECT I needed the PARM RENT. In SYS1.SHASSAMP is HASIASM which has NORENT. In SYS1.SHASSAMP is HASX40A which is what I am modifying. I added the SYS1.SHASMAC DD to the JCL. The z/OS V1R13.0 JES2 Installation Exits talks about Exit 40: Modifying SYSOUT characteristics. I have RMODE ANY. It also says I need AMODE 31. The HLASM V1R5 Language Reference has figure 26 AMODE/RMODE Defaults. It says RMODE 31 (was ANY) defaults to AMODE 31. I think I have meet the requirements. The first two lines in HASX40A are: *PROCESS USING(WARN(15)),SUPRWARN(324,420,436,437) ACONTROL CPAT(NOSYSL,NOCASE),FLAG(PAGE0) But the *PROCESS generates two messages. It looks like WARN(15) may be obsolete. ** ASMA437N Attempt to override invocation parameter in a *PROCESS statement. Suboption 15 of USING option ignored. ** ASMA420N Error in a *PROCESS statement parameter - USING(WARN(15)) My program assembles clean with this JCL: //ASM EXEC PGM=ASMA90, // PARM='NORENT,DECK,NOOBJ,USING(WARN(3))', // REGION=6M //SYSLIB DD DISP=SHR,DSN=SYS1.MACLIB // DD DISP=SHR,DSN=SYS1.SHASMAC // DD DISP=SHR,DSN=SYS1.MODGEN,VOL=SER=S7XPA2,UNIT=3390 //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(10,1)) //SYSUT2 DD UNIT=SYSDA,SPACE=(CYL,(10,1)) //SYSUT3 DD UNIT=SYSDA,SPACE=(CYL,(10,1)) //SYSPRINT DD SYSOUT=* //SYSINDD DISP=SHR,DSN=SYS2.LIBRSRC.CNTL(HASX40) //SYSPUNCH DD DSN=OBJ,DISP=(,PASS),SPACE=(CYL,(3,1)), // UNIT=SYSDA,DCB=BLKSIZE=1600 //* //LKEDEXEC PGM=IEWL,PARM='XREF,LIST,RENT,REFR,AC=0' //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(10,1)) //SYSPRINT DD SYSOUT=* //OBJ DD DSN=OBJ,DISP=(OLD,DELETE) //SYSLMOD DD DISP=SHR,DSN=SYS2.LINKLIB //SYSLIN DD * INCLUDE OBJ ENTRY HASX40 NAME HASX40(R) /* Q). Do I want NORENT for my JES2 EXIT 40? It deals with being reentrant. Not sure what this exit should have. Q). Does my PARM=USING(WARN(3)) override the *PROCESS USING(WARN(15))? Then I can remove USING from the *PROCESS (and maybe not get any messages). Thank you, Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Large BLKSIZE
We're having ongoing 'discussions' with our tape vendor over through-put performance. Vendor is suggesting that we should be using modern man-size blocks like 256K. I did some simple testing yesterday to satisfy myself that--whatever it might take to super-size our tape file blocks--simply adding BLKSIZE=some-large-number to a DD card will not cause the creation of very large blocks. After running such a job with an existing RYO program, the resulting BLKSIZE was in fact 32K. No error messages, just no big blocks. Am I right in asserting that, whatever benefit we might derive from uber-blocks, we cannot get there by fiddling with JCL? . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Man Pages for Ported Tools?
Trust, but verify. Yes I did think that I need to go to all the trouble (which really wasn't much). I've had occasions where an extension has been hijacked by an unrelated product. Not usually done by IBM. And I do many things for my own amusement. In addition, by doing this, I can read the _entire_ manual. It has much more than can be found via the man command. Each cat, his own rat. On Wed, Aug 21, 2013 at 9:56 AM, Mark Post mp...@suse.com wrote: On 8/21/2013 at 08:38 AM, John McKown john.archie.mck...@gmail.com wrote: I then created an empty data set with those characteristics, and did a binary copy (cp -B) of the hpuza200.book file into it. Guess what? I could then open it in ISPF BookManager READ! BookManager is alive and well and living in z/OS UNIX! Given the name of the file is hpuza200.book, did you really think you had to go to all that trouble? :) Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large BLKSIZE
I think it will depend on what is creating the LBI file IDCMAS does not support LBI. Running two sets of JCL: The first set used IEBGENER with an output blocksize of 65520. The resulting tape actually had a blocksize of 65520. The same input data set using IDCAMS Repro with an output BLKSIZE specified as 65520, however, results in the output Blksize of 32720. Answer The problem has to do with the BLKSIZE. In the z/OS DFSMS Access Method Services for Catalogs manual (Document Number SC26-7394-03) it states in section 30.1 REPRO Parameters. REPRO cannot be used if source or target tape data set has a BLKSIZE larger than 32760 bytes. Your RYO needs to check some bits for LBI and then handle it. The large block interface (LBI) lets your program |handle much larger blocks with BSAM or QSAM. On the current level of the system you can use LBI with BSAM, BPAM, and QSAM for any kind of data set except unit record or a TSO/E terminal. Currently blocks of more than 32 760 bytes are supported only on tape, dummy |data sets, and BSAM UNIX files. You request LBI by coding a BLKSIZE value, even 0, in the DCBE macro or by turning on the DCBEULBI bit before completion of the DCB OPEN exit. Coding BLKSIZE causes the bit to be on. It is best if this bit is on before you issue the OPEN macro. That lets OPEN merge a large block size into the DCBE. Your DCB OPEN exit can test bit DCBESLBI to learn if the access method supports LBI. If your program did not request unlike attributes processing (by turning on bit DCBOFPPC) before issuing OPEN, then DCBESLBI being on means that all the data sets in the concatenation support LBI. If your program requested unlike attributes processing before OPEN, then DCBESLBI being on each time that the system calls your DCB OPEN exit or JFCBE exit means only that the next data set supports LBI. After the exit, OPEN leaves DCBESLBI on only if DCBEULBI also is on. Your exit routine can change DCBEULBI. Never change DCBESLBI. I know you probably know this. So this is just for anyone searching this topic. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Wednesday, August 21, 2013 8:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Large BLKSIZE We're having ongoing 'discussions' with our tape vendor over through-put performance. Vendor is suggesting that we should be using modern man-size blocks like 256K. I did some simple testing yesterday to satisfy myself that--whatever it might take to super-size our tape file blocks--simply adding BLKSIZE=some-large-number to a DD card will not cause the creation of very large blocks. After running such a job with an existing RYO program, the resulting BLKSIZE was in fact 32K. No error messages, just no big blocks. Am I right in asserting that, whatever benefit we might derive from uber-blocks, we cannot get there by fiddling with JCL? . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large BLKSIZE
http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.idad400%2Fblksz.htm Use BLKSIZE=0. It will use the optimum (largest) blocksize that is valid. 32K, 64K, or 256K. On Wed, Aug 21, 2013 at 10:53 AM, Skip Robinson jo.skip.robin...@sce.com wrote: We're having ongoing 'discussions' with our tape vendor over through-put performance. Vendor is suggesting that we should be using modern man-size blocks like 256K. I did some simple testing yesterday to satisfy myself that--whatever it might take to super-size our tape file blocks--simply adding BLKSIZE=some-large-number to a DD card will not cause the creation of very large blocks. After running such a job with an existing RYO program, the resulting BLKSIZE was in fact 32K. No error messages, just no big blocks. Am I right in asserting that, whatever benefit we might derive from uber-blocks, we cannot get there by fiddling with JCL? -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DASD INDEX Display
Does anyone know a command (or batch job) that will display the INDEX information of a dasd volume? The DSLIST panel in ISPF only show the VTOC info. Thanks, Roger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DASD INDEX Display
Do you wish to list the SYS1.VTOCIX or the SYS1.VVDS or other? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Roger Craig Sent: Wednesday, August 21, 2013 9:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DASD INDEX Display Does anyone know a command (or batch job) that will display the INDEX information of a dasd volume? The DSLIST panel in ISPF only show the VTOC info. Thanks, Roger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DASD INDEX Display
What do you want to know besides whether the index is enabled or not? :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Roger Craig :: Sent: Wednesday, August 21, 2013 9:14 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: DASD INDEX Display :: :: Does anyone know a command (or batch job) that will display the INDEX :: information of a dasd volume? The DSLIST panel in ISPF only show the :: VTOC :: info. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
I note the presence of quotes in the RELATE but not the NAME. If not a
byproduct of excessive munging, this could be a part of the difficulty.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of mf db
Sent: Wednesday, August 21, 2013 3:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Deleting Alias
Hello,
I was able to delete a alias from a usercatalog with a below parms :
DEL ENTRYNAME ALIAS CAT(USERCAT)
Defining alias to a Non Vsam :
DEF ALIAS (NAME(XX..)-
RELATE('X..ZZZ.'))
But when I tried checking the alias with ISPF 3.4 option I couldn't see the
entry being visible.
When I do listcat against the dataset ..ZZZ. but I could see the
alias relation for XXX... Not sure why the alias entry is not visible.
I tried even deleting and defining back but no luck. I do get a message as
duplicate dataset name when I try defining it again.
IDC3013I DUPLICATE DATA SET NAME
Z/OS : 1.13
Could some please shed some light on the above.
/Peter
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Ok,
1 ) I did deleted the alias pointing to the usercatalog.- RC-0 and Alias
did not appear in listcat against the NON-VSAM dataset.
2 ) Again I defined with same name relating to the Non Vsam Dataset - RC-0
3 ) Listcat against the NON-VSAM dataset shows me the Alias which I defined
in previous step.
4 ) Here Alias and NON-vsam are pointing towards the same Usercatalog.
5 ) All the required options are enabled under ISPF 3.4 browse option.
6 ) The usercatalog is very much connected to the correct master catalog.
7 ) Usercatalog is sitting on the SMS managed volume.
But not sure why the system isn't recognizing the alias which was defined.
On Wed, Aug 21, 2013 at 9:05 PM, Skip Robinson jo.skip.robin...@sce.comwrote:
Sorry about that. NSCR is valid only for DEL NONVSAM. Not for alias. Leave
out that operand. No ill consequences.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: mf db dbajava...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 08/21/2013 08:26 AM
Subject:Re: Deleting Alias
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
The NOSCRATCH does not takes up :
DEL .linklib ALIAS CATALOG(ICF.UCAT.CAT2) NOSCRATCH
IDC3226I INCONSISTENT PARAMETERS INVOLVING 'NOSCRATCH'
On Wed, Aug 21, 2013 at 8:41 PM, Skip Robinson
jo.skip.robin...@sce.comwrote:
Catalog aliases (as opposed to PDS member aliases) have two different
uses.
1. By far the most common is high-level-qualifier such as TSO userid. In
this case, the alias itself lives in the master catalog and
points--RELATEs--to a user catalog that contains one or more actual DSNs
that all begin with the HLQ. To delete such an alias, you *must not*
name
the user catalog in the command because user cat name is just part of
the
entry you are deleting. You are deleting the alias (implicitly) from the
master catalog.
DEL 'hlq' ALIAS
2. A less common usage but one we deploy to manage ServerPac data sets
relates a fully qualified DSN in a user catalog to a different name. For
example:
'OSR13.SYS1.LINKILIB' is defined in 'MVSR13.ICF.MASTER' as
pointing--RELATing--to 'SYS1.LINKLIB' on the SMPE target volume. In
order
for this to work, there must still be an HLQ alias 'OSR13'
pointing--RELATing--to the user catalog as in (1). To delete the fully
qualified alias data set name from the user catalog, you must name the
user catalog because that's where the alias entry actually lives.
DEL 'fully-qualified-name' ALIAS CAT('usercat-name') NOSCRATCH
I threw in NOSCRATCH because otherwise your actual data set will
disappear. Unless that's what you want.
3. If you are getting 'duplicate name' when you try to redefine the
alias,
then you did not actually delete the alias in the first place. That
would
be the result of including user cat name in the command in (1) above.
The
command would fail, and the alias would remain in the master catalog.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: mf db dbajava...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 08/21/2013 07:40 AM
Subject:Re: Deleting Alias
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Elardus,
I tried viewing via ISMF and I could see the alias entry pointing the
same
usercatalog, but when I type Browse agains the alias I get a message as
Dataset not catalogued
On Wed, Aug 21, 2013 at 8:01 PM, Paul Gilmartin
paulgboul...@aim.comwrote:
On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote:
DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED
hlq
must be in MYUCAT1
You can control which catalog the TED alias is created in, but if the
catalogs are different you lose either way. If you create TED in
BOB's catalog, catalog search fails to find TED; if you create TED
in its proper catalog, catalog search fails to find BOB.
I may have that backwards, but it is close. Bottom line, the example
IBM
has in the book for doing this is very bad. I will be opening a
request
for
updating that to a more reasonable example....
Rather, that should be a Requirement that it be done right, not
a RCF for documentation that it is done wrong.
... Second, from the document it
appears that the HLQs should be in the same UCAT. At least that is
my
understanding from reading the IBM doc (which is very nebulous at
best).
And I do not believe that you are required to use the CAT parameter
in
the
DEF ... ALIAS RELATE() function
-- gil
--
For
Re: Large BLKSIZE
On 08/21/2013 10:53 AM, Skip Robinson wrote: We're having ongoing 'discussions' with our tape vendor over through-put performance. Vendor is suggesting that we should be using modern man-size blocks like 256K. I did some simple testing yesterday to satisfy myself that--whatever it might take to super-size our tape file blocks--simply adding BLKSIZE=some-large-number to a DD card will not cause the creation of very large blocks. After running such a job with an existing RYO program, the resulting BLKSIZE was in fact 32K. No error messages, just no big blocks. Am I right in asserting that, whatever benefit we might derive from uber-blocks, we cannot get there by fiddling with JCL? . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com ... I thought all tape drives since 3490 always did hardware compression and also created hardware super blocks on physical tape, making the efficiency of physical tape writes independent of logical block size. If the application and JCL allow for enough buffer blocks for the tape data set, I would expect normal QSAM processing would send multiple 32K logical blocks to the tape controller in a single I/O and come very close to the channel efficiency that larger logical blocks would achieve - perhaps with somewhat larger CPU usage for the additional buffer handling, but that should have minimal impact on tape performance. One thing at least in the past that would kill tape throughput on high-density drives was if there was a bottleneck in getting bytes through the tape controller fast enough to keep the tape physically moving - from application processing delays, channel/controller contention with other jobs or drives, whatever. Once the tape had to physically stop, the Inter-Block Gaps were so small by comparison with tape stopping distance that slow-speed tape positioning was required before writing could start for the next physical super-block. If that happened consistently, throughput was drastically degraded. You might just try playing games with number of buffers on the DDs. I think the default is five, but in the days of slow tape drives two was frequently sufficient for tape I/O and some JCL might still reflect that practice. If you want to allow for the possibility of 256K transfers with 32K logical blocks, that suggests a minimum somewhere between 9 to 16 buffers. -- 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
Re: Large BLKSIZE
Thanks to Lizette for pointing out IEBGENER, I ran an IEBGENER (alias for ICEGENER) copy with BLKSIZE around 256K and got that result according to RMM. Not surprising for ICEGENER. Then I ran with IBMGENER, the ancient utility, and got the same result (!). I infer from my testing that some programs are designed to accommodate LBI if needed. My RYO program, straight old QSAM, does not do that. The point of this exercise is to insist to the tape vendor that we cannot just write larger blocks by overriding JCL. Thanks to all who contributed. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Lizette Koehler stars...@mindspring.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 08/21/2013 09:03 AM Subject:Re: Large BLKSIZE Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU I think it will depend on what is creating the LBI file IDCMAS does not support LBI. Running two sets of JCL: The first set used IEBGENER with an output blocksize of 65520. The resulting tape actually had a blocksize of 65520. The same input data set using IDCAMS Repro with an output BLKSIZE specified as 65520, however, results in the output Blksize of 32720. Answer The problem has to do with the BLKSIZE. In the z/OS DFSMS Access Method Services for Catalogs manual (Document Number SC26-7394-03) it states in section 30.1 REPRO Parameters. REPRO cannot be used if source or target tape data set has a BLKSIZE larger than 32760 bytes. Your RYO needs to check some bits for LBI and then handle it. The large block interface (LBI) lets your program |handle much larger blocks with BSAM or QSAM. On the current level of the system you can use LBI with BSAM, BPAM, and QSAM for any kind of data set except unit record or a TSO/E terminal. Currently blocks of more than 32 760 bytes are supported only on tape, dummy |data sets, and BSAM UNIX files. You request LBI by coding a BLKSIZE value, even 0, in the DCBE macro or by turning on the DCBEULBI bit before completion of the DCB OPEN exit. Coding BLKSIZE causes the bit to be on. It is best if this bit is on before you issue the OPEN macro. That lets OPEN merge a large block size into the DCBE. Your DCB OPEN exit can test bit DCBESLBI to learn if the access method supports LBI. If your program did not request unlike attributes processing (by turning on bit DCBOFPPC) before issuing OPEN, then DCBESLBI being on means that all the data sets in the concatenation support LBI. If your program requested unlike attributes processing before OPEN, then DCBESLBI being on each time that the system calls your DCB OPEN exit or JFCBE exit means only that the next data set supports LBI. After the exit, OPEN leaves DCBESLBI on only if DCBEULBI also is on. Your exit routine can change DCBEULBI. Never change DCBESLBI. I know you probably know this. So this is just for anyone searching this topic. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Wednesday, August 21, 2013 8:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Large BLKSIZE We're having ongoing 'discussions' with our tape vendor over through-put performance. Vendor is suggesting that we should be using modern man-size blocks like 256K. I did some simple testing yesterday to satisfy myself that--whatever it might take to super-size our tape file blocks--simply adding BLKSIZE=some-large-number to a DD card will not cause the creation of very large blocks. After running such a job with an existing RYO program, the resulting BLKSIZE was in fact 32K. No error messages, just no big blocks. Am I right in asserting that, whatever benefit we might derive from uber-blocks, we cannot get there by fiddling with JCL? . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large BLKSIZE
On Wed, 21 Aug 2013 08:53:25 -0700, Skip Robinson jo.skip.robin...@sce.com wrote: We're having ongoing 'discussions' with our tape vendor over through-put performance. Vendor is suggesting that we should be using modern man-size blocks like 256K. I did some simple testing yesterday to satisfy myself that--whatever it might take to super-size our tape file blocks--simply adding BLKSIZE=some-large-number to a DD card will not cause the creation of very large blocks. After running such a job with an existing RYO program, the resulting BLKSIZE was in fact 32K. No error messages, just no big blocks. Am I right in asserting that, whatever benefit we might derive from uber-blocks, we cannot get there by fiddling with JCL? . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The application/utility being used must also provide LBI support, normally. This condition would be similar to application support for DSNTYPE=LARGE and EAV/EAS, as it stands. For example, IDCAMS REPRO does support LBI, starting at z/OS 2.1, per DOC. And DFDSS ADRDSSU supports it currently, of course short-circuited if someone has BLKSIZE=32760 hardcoded. And, for comparison, SAS 9.2 provided limited support, but only for external tape-directed file access, not SAS databases residing on tape -- that is coming soon. Suggest contacting IBM and ISVs through their support reference database search resources on a product by product basis -- and don't get hopes up that all ISVs have done their 'technology support' due-diligence on the customer's behalf. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large BLKSIZE
I defer to Joel on the physics of traditional tape, but this happens to be virtual tape. No moving parts (other than internal disk). As for desirable block size, we're just going by what the vendor has been telling us. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Joel C. Ewing jcew...@acm.org To: IBM-MAIN@LISTSERV.UA.EDU, Date: 08/21/2013 10:31 AM Subject:Re: Large BLKSIZE Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On 08/21/2013 10:53 AM, Skip Robinson wrote: We're having ongoing 'discussions' with our tape vendor over through-put performance. Vendor is suggesting that we should be using modern man-size blocks like 256K. I did some simple testing yesterday to satisfy myself that--whatever it might take to super-size our tape file blocks--simply adding BLKSIZE=some-large-number to a DD card will not cause the creation of very large blocks. After running such a job with an existing RYO program, the resulting BLKSIZE was in fact 32K. No error messages, just no big blocks. Am I right in asserting that, whatever benefit we might derive from uber-blocks, we cannot get there by fiddling with JCL? . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com ... I thought all tape drives since 3490 always did hardware compression and also created hardware super blocks on physical tape, making the efficiency of physical tape writes independent of logical block size. If the application and JCL allow for enough buffer blocks for the tape data set, I would expect normal QSAM processing would send multiple 32K logical blocks to the tape controller in a single I/O and come very close to the channel efficiency that larger logical blocks would achieve - perhaps with somewhat larger CPU usage for the additional buffer handling, but that should have minimal impact on tape performance. One thing at least in the past that would kill tape throughput on high-density drives was if there was a bottleneck in getting bytes through the tape controller fast enough to keep the tape physically moving - from application processing delays, channel/controller contention with other jobs or drives, whatever. Once the tape had to physically stop, the Inter-Block Gaps were so small by comparison with tape stopping distance that slow-speed tape positioning was required before writing could start for the next physical super-block. If that happened consistently, throughput was drastically degraded. You might just try playing games with number of buffers on the DDs. I think the default is five, but in the days of slow tape drives two was frequently sufficient for tape I/O and some JCL might still reflect that practice. If you want to allow for the possibility of 256K transfers with 32K logical blocks, that suggests a minimum somewhere between 9 to 16 buffers. -- 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
Re: Deleting Alias
On 8/21/2013 10:39 AM, John Gilmore wrote: Aliases are most useful for PDS and PDSE members, and they are handled very differently in the two. Beauty is in the eye of the beholder. As useful as member aliases are, I find data set aliases more useful. For example, our third party products were usually referred to as product.library or SYS1.product.library, but those were alias entries for product.VnnRnnMnn.library or the SYS1. equivalent. This allows product support without a constant replacement of procedures, and allows fallback simply by recataloging the alias. Also the procedures had a parameter to allow inserting the version level, allowing us to keep service bureau customers with special requirements happy. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Data-set aliases are certainly useful for keeping such names as ASSEMBLE or BIND unchanged when new versions are brought into use. They permit an installation to control which version default-taking users will invoke. I made my comment because it seemed to me that things were being done or, better, attempted with data-set aliases that are better done with member-name ones. I still think this. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TRSMAIN
Yes. However, I suggest use of AMATERSE. The supported version of TRSMAIN. HTH, snip A data set is compressed using TRSMAIN on z/OS. It is transmitted, using binary format, to a non-z/OS server. For whatever reason the compressed file on the server is incomplete. When the compressed file is transmitted, using binary format, back to a z/OS system, and uncompressed, will TRSMAIN know the data set is incomplete? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Dumb Question - Applying maintenance on shared sysplex root
Hello Everyone , Apologize in advance for this dumb question . I have a requirement to put some maintenance on Java filesystem which is currently mounted on a shared sysplex root .We have 4 lpars (including the sandbox) in same sysplex sharing the root file system . My customer wants to test the change on sandbox system before i roll out on other lpars.So , it just looks as below /JAVA64 = OMVS.JAVA64.ZFS I thought of taking a copy of OMVS.JAVA64.ZFS with a different name and mount it on a newly created mount point (such as /JAVA64T) for sandbox lpar specifically . But i am not sure who all would be still looking for the original mount point /JAVA64 . Is there any way i can test it specifically for sandbox lpar without disturbing the other 3 lpars ? Any help would be much appreciated Thanks in Advance, Baby -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
In of3e905769.0a5fdaa3-on88257bce.0050dfe9-88257bce.00537...@sce.com, on 08/21/2013 at 08:11 AM, Skip Robinson jo.skip.robin...@sce.com said: Catalog aliases (as opposed to PDS member aliases) have two different uses. 3. MLA -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 EXIT 40 ASMA90 Parm Question
In cc42e2f56d60f24fb8a6bcc639d1d96306b4b...@samtcasxmb13.usa.dce.usps.gov, on 08/21/2013 at 03:39 PM, Hansen, Dave L - Eagan, MN dave.l.han...@usps.gov said: Last time I was assembling a CSECT I needed the PARM RENT. It might be needed in the link step, but in the assembly step it just turns on a diagnostic. The z/OS V1R13.0 You should be looking at the manuals for HLASM V6R1, not V5R1. It looks like WARN(15) may be obsolete. No. ** ASMA437N Attempt to override invocation parameter in a *PROCESS statement. Suboption 15 of USING option ignored. See OVERRIDE. PARM='NORENT,DECK,NOOBJ,USING(WARN(3))', Do you get bogus warnings with RENT? If not, I'd advise using it. Q). Do I want NORENT for my JES2 EXIT 40? Yes, unless you get bogus warnings. Q). Does my PARM=USING(WARN(3)) override the *PROCESS USING(WARN(15))? Yes, unless the *PROCESS specifies OVERRIDE. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 EXIT 40 ASMA90 Parm Question
Reentrant code considerations are contingent on the calling environment.An exit routine called from the JES2 main task must be reentrant in the JES2 sense. The JES2 dispatching unit, commonly called JES2 processors, running under a processor control element (PCE) perform the processing for the JES2 main task. The JES2 dispatcher controls what PCE is currently active (that is, what JES2 processor is currently running). Because a JES2 processor doesn't relinquish control to another JES2 processor involuntarily, an exit routine, invoked out of a JES2 main task processor may use a nonreentrant work area; the work area is serialized if the exit routine doesn't issue a $WAIT macro or until the exit routine or service called from an exit routine does issue the $WAIT macro. When the exit routine issues the $WAIT macro directly or through a called routine, control returns to the JES2 dispatcher and the serialization on the nonreentrant work area ceases. The nonreentrant work area may also be passed between exit routines, or between an exit routine and JES2, before a $WAIT macro call. Work areas to be used across a $WAIT must either be within the processor work area established as part of the processor control element (PCE) or else must be directly owned by the processor. In the same JES2 reentrant sense, an exit routine may search or manipulate a JES2 queue providing it has ownership of the queue and doesn't issue a $WAIT macro until this action is completed.An exit routine called from a JES2 subtask, from the user environment, or from the FSS environment must be reentrant in the MVS sense. The exit routine must be capable of taking an MVS interrupt at any point in its processing. The exit routine must be able to handle the simultaneity of execution with other subtasks and user address space, or functional subsystem (FSS) routines and with the JES2 main task.The following actions may produce unpredictable results: Modifying control block fields designed for use by the JES2 main task only (for example, $DOUBLE, $GENWORK, and so on.) Accessing checkpointed data from the subtask, user, or FSS environment. Mike Michael K. Toole Sr. I.T. Consultant The Auto Club Group 1 Auto Club Drive Dearborn, Mi. 48126 313-336-1783 mto...@aaamichigan.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hansen, Dave L - Eagan, MN Sent: Wednesday, August 21, 2013 11:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JES2 EXIT 40 ASMA90 Parm Question CROSS-POSTED to ASSEMBLER-LIST and IBM-MAIN Dear Group, I worked with IBM to determine the best way to move print from one JES2 spool to another was by using EXIT 40. Last time I was assembling a CSECT I needed the PARM RENT. In SYS1.SHASSAMP is HASIASM which has NORENT. In SYS1.SHASSAMP is HASX40A which is what I am modifying. I added the SYS1.SHASMAC DD to the JCL. The z/OS V1R13.0 JES2 Installation Exits talks about Exit 40: Modifying SYSOUT characteristics. I have RMODE ANY. It also says I need AMODE 31. The HLASM V1R5 Language Reference has figure 26 AMODE/RMODE Defaults. It says RMODE 31 (was ANY) defaults to AMODE 31. I think I have meet the requirements. The first two lines in HASX40A are: *PROCESS USING(WARN(15)),SUPRWARN(324,420,436,437) ACONTROL CPAT(NOSYSL,NOCASE),FLAG(PAGE0) But the *PROCESS generates two messages. It looks like WARN(15) may be obsolete. ** ASMA437N Attempt to override invocation parameter in a *PROCESS statement. Suboption 15 of USING option ignored. ** ASMA420N Error in a *PROCESS statement parameter - USING(WARN(15)) My program assembles clean with this JCL: //ASM EXEC PGM=ASMA90, // PARM='NORENT,DECK,NOOBJ,USING(WARN(3))', // REGION=6M //SYSLIB DD DISP=SHR,DSN=SYS1.MACLIB // DD DISP=SHR,DSN=SYS1.SHASMAC // DD DISP=SHR,DSN=SYS1.MODGEN,VOL=SER=S7XPA2,UNIT=3390 //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(10,1)) //SYSUT2 DD UNIT=SYSDA,SPACE=(CYL,(10,1)) //SYSUT3 DD UNIT=SYSDA,SPACE=(CYL,(10,1)) //SYSPRINT DD SYSOUT=* //SYSINDD DISP=SHR,DSN=SYS2.LIBRSRC.CNTL(HASX40) //SYSPUNCH DD DSN=OBJ,DISP=(,PASS),SPACE=(CYL,(3,1)), // UNIT=SYSDA,DCB=BLKSIZE=1600 //* //LKEDEXEC PGM=IEWL,PARM='XREF,LIST,RENT,REFR,AC=0' //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(10,1)) //SYSPRINT DD SYSOUT=* //OBJ DD DSN=OBJ,DISP=(OLD,DELETE) //SYSLMOD DD DISP=SHR,DSN=SYS2.LINKLIB //SYSLIN DD * INCLUDE OBJ ENTRY HASX40 NAME HASX40(R) /* Q). Do I want NORENT for my JES2 EXIT 40? It deals with being reentrant. Not sure what this exit should have. Q). Does my PARM=USING(WARN(3)) override the *PROCESS USING(WARN(15))? Then I can remove USING from the *PROCESS (and maybe not get any messages). Thank you, Dave -- For IBM-MAIN subscribe / signoff / archive access
Re: Dumb Question - Applying maintenance on shared sysplex root
Hello Baby, You seem to be using sysplex shared file systems. If you do the fuser -cu /JAVA64 command under UID=0 you will see who is currently using that file system. Preferably, that /JAVA64 folder should be a symbolic link, pretty much like your /usr, /var and so. That would require some setup though (and an outage of the users if you wish to keep using the same path). Maybe the easier to do now, which wouldn't require an outage, would be just doing just what you said. Regards, Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of baby eklavya Sent: Wednesday, August 21, 2013 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dumb Question - Applying maintenance on shared sysplex root Hello Everyone , Apologize in advance for this dumb question . I have a requirement to put some maintenance on Java filesystem which is currently mounted on a shared sysplex root .We have 4 lpars (including the sandbox) in same sysplex sharing the root file system . My customer wants to test the change on sandbox system before i roll out on other lpars.So , it just looks as below /JAVA64 = OMVS.JAVA64.ZFS I thought of taking a copy of OMVS.JAVA64.ZFS with a different name and mount it on a newly created mount point (such as /JAVA64T) for sandbox lpar specifically . But i am not sure who all would be still looking for the original mount point /JAVA64 . Is there any way i can test it specifically for sandbox lpar without disturbing the other 3 lpars ? Any help would be much appreciated Thanks in Advance, Baby -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumb Question - Applying maintenance on shared sysplex root
Thanks Leo for quick response . When i checked the same for /JAVA31 ,it was actually a symbolic link from /usr/lpp/java which is actually a filesystem mounted over the VERSION root .So ,that looks okay to me as i can mount a clone of that filesystem on a new VERSION root specific to sandbox lpar . Then change the symbolic link as required . But when it comes to /JAVA64 , I do not see any symbolic links like i saw in the case of /JAVA31 . Is there any other way to check if /JAVA64 is a symbolic link or not ? Regards , Baby On Thu, Aug 22, 2013 at 2:08 AM, Leonardo Vaz leonardo@cn.ca wrote: Hello Baby, You seem to be using sysplex shared file systems. If you do the fuser -cu /JAVA64 command under UID=0 you will see who is currently using that file system. Preferably, that /JAVA64 folder should be a symbolic link, pretty much like your /usr, /var and so. That would require some setup though (and an outage of the users if you wish to keep using the same path). Maybe the easier to do now, which wouldn't require an outage, would be just doing just what you said. Regards, Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of baby eklavya Sent: Wednesday, August 21, 2013 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dumb Question - Applying maintenance on shared sysplex root Hello Everyone , Apologize in advance for this dumb question . I have a requirement to put some maintenance on Java filesystem which is currently mounted on a shared sysplex root .We have 4 lpars (including the sandbox) in same sysplex sharing the root file system . My customer wants to test the change on sandbox system before i roll out on other lpars.So , it just looks as below /JAVA64 = OMVS.JAVA64.ZFS I thought of taking a copy of OMVS.JAVA64.ZFS with a different name and mount it on a newly created mount point (such as /JAVA64T) for sandbox lpar specifically . But i am not sure who all would be still looking for the original mount point /JAVA64 . Is there any way i can test it specifically for sandbox lpar without disturbing the other 3 lpars ? Any help would be much appreciated Thanks in Advance, Baby -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DASD INDEX Display
Most of the time this is something is 'broke'. A general scenario is IEHLIST of the pack to look for overlaps. If restoring a file to another pack it is helpful to now the UCAT where it was. ADRDSSU print with DUMP of VVDS should show DSN and UCAT. Then to further narrow it down IDCAMs DIAGNOSE for UCAT or VVDS can point out discrepancies. If the DIRF bit is flicked on you should see a message in the LOG INDEXED VTOC disabled. In the olden days we would run batch jobs to allocate temp dsns on packs in question to rebuild VTOC, but haven't done this in many moons-since RAID 5. If it's not a 'size' problem can just run CNVTIX to rebuild the Indexed VTOC. PDS86 and ISMF indicate VTOC construct with I. In a message dated 08/21/13 11:46:34 Central Daylight Time, retired-mainfra...@q.com writes: What do you want to know besides whether the index is enabled or not? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TRSMAIN
On 21 August 2013 14:59, Richard Pinion rpin...@netscape.com wrote: A data set is compressed using TRSMAIN on z/OS. It is transmitted, using binary format, to a non-z/OS server. For whatever reason the compressed file on the server is incomplete. When the compressed file is transmitted, using binary format, back to a z/OS system, and uncompressed, will TRSMAIN know the data set is incomplete? Depends on what you mean by incomplete. A TRSMAIN/AMATERSE compressed data stream consists of a short header, and then 12-bit units with a value from 1 to 4096, terminated by a unit of zeros. The header does not contain an overall length field. (There is also a trailer, but I'm not sure it's used for anything.) If decompression hits EOF before seeing that ending zero unit, it should complain, though I don't know how elegantly. So if your data is truncated, it can and should be detected. But if you restore your damaged data into an FB dataset, the last block may be zero padded regardless, so a silent failure seems quite possible. If your compressed stream is missing a chunk in the middle, it's possible - and with anything bigger than a very small dataset, even likely - that what remains is decodable, but after the gap it certainly won't decode into anything much like the original. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
At this point it looks like you need to cut and paste the complete output from the job so we have a chance to determine what is really happening. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of mf db :: Sent: Wednesday, August 21, 2013 10:26 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Deleting Alias :: :: Ok, :: :: 1 ) I did deleted the alias pointing to the usercatalog.- RC-0 and Alias :: did not appear in listcat against the NON-VSAM dataset. :: 2 ) Again I defined with same name relating to the Non Vsam Dataset - :: RC-0 :: 3 ) Listcat against the NON-VSAM dataset shows me the Alias which I :: defined :: in previous step. :: 4 ) Here Alias and NON-vsam are pointing towards the same Usercatalog. :: 5 ) All the required options are enabled under ISPF 3.4 browse option. :: 6 ) The usercatalog is very much connected to the correct master catalog. :: 7 ) Usercatalog is sitting on the SMS managed volume. :: :: But not sure why the system isn't recognizing the alias which was :: defined. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SCRT question
Has anybody successfully FTPd the SCRT report in a batch job to a zFS file? When I try it, I get a weird file. When I use a Windows, the file transfers without a problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
On Wed, 21 Aug 2013 23:16:17 +, Mark Yuhas wrote: Has anybody successfully FTPd the SCRT report in a batch job to a zFS file? When I try it, I get a weird file. When I use a Windows, the file transfers without a problem. People will want much more information: o What are the attributes of the SCRT report? o Was the zFS file accessed by the client or the server (and presumably the SCRT report vice-versa)? o What were the specific FTP subcommands? o Were the SCRT report and the zFS file on the same system? If so, why not use IEBGENER? o In the Windows instance, was Windows the client or the server? o What were the specific FTP subcommands transferring to Windows? o Can you be more specific about weird? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
o Were the SCRT report and the zFS file on the same system? If so, why not use IEBGENER? Or OCOPY? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TRSMAIN
It's an easy JCL exercise to conduct an experiment to confirm what happens: TRSMAIN/AMATERSE will read a truncated tersed file and never detect it was truncated. I copied a 105472 byte valid tersed file into a DISP=(,CATLG,CATLG),SPACE=(TRK,(1)). The original untersed to 360,480 bytes, while the truncated file untersed to only 48152, and there was no message nor warning that the input file was short. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, August 21, 2013 5:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TRSMAIN On 21 August 2013 14:59, Richard Pinion rpin...@netscape.com wrote: A data set is compressed using TRSMAIN on z/OS. It is transmitted, using binary format, to a non-z/OS server. For whatever reason the compressed file on the server is incomplete. When the compressed file is transmitted, using binary format, back to a z/OS system, and uncompressed, will TRSMAIN know the data set is incomplete? Depends on what you mean by incomplete. A TRSMAIN/AMATERSE compressed data stream consists of a short header, and then 12-bit units with a value from 1 to 4096, terminated by a unit of zeros. The header does not contain an overall length field. (There is also a trailer, but I'm not sure it's used for anything.) If decompression hits EOF before seeing that ending zero unit, it should complain, though I don't know how elegantly. So if your data is truncated, it can and should be detected. But if you restore your damaged data into an FB dataset, the last block may be zero padded regardless, so a silent failure seems quite possible. If your compressed stream is missing a chunk in the middle, it's possible - and with anything bigger than a very small dataset, even likely - that what remains is decodable, but after the gap it certainly won't decode into anything much like the original. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TRSMAIN
On 21 August 2013 20:39, Barry Merrill ba...@mxg.com wrote: It's an easy JCL exercise to conduct an experiment to confirm what happens: TRSMAIN/AMATERSE will read a truncated tersed file and never detect it was truncated. I copied a 105472 byte valid tersed file into a DISP=(,CATLG,CATLG),SPACE=(TRK,(1)). The original untersed to 360,480 bytes, while the truncated file untersed to only 48152, and there was no message nor warning that the input file was short. Can you look at the last record in the truncated tersed dataset and see if it's zero-padded? Strictly one should look for a 12-bit zero, but a run of three of the 8-bit kind we're more used to would more than do the trick. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TRSMAIN
How could it? GENER did the truncation, AMATERSE was not involved, so the last bytes are whatever the last bytes were. The file just ended with one track filled and B37 for the GENER. But I did look and there are no 00 bytes in the last 20 or so bytes of the last 1024 byte record that had been created by AMATERSE. Then AMATERSE just decompressed the bytes that were there in that one track. Barry -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, August 21, 2013 7:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TRSMAIN On 21 August 2013 20:39, Barry Merrill ba...@mxg.com wrote: It's an easy JCL exercise to conduct an experiment to confirm what happens: TRSMAIN/AMATERSE will read a truncated tersed file and never detect it was truncated. I copied a 105472 byte valid tersed file into a DISP=(,CATLG,CATLG),SPACE=(TRK,(1)). The original untersed to 360,480 bytes, while the truncated file untersed to only 48152, and there was no message nor warning that the input file was short. Can you look at the last record in the truncated tersed dataset and see if it's zero-padded? Strictly one should look for a 12-bit zero, but a run of three of the 8-bit kind we're more used to would more than do the trick. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TRSMAIN
I tried your suggestion and had the same results as you described Mr. Merrill. --- ba...@mxg.com wrote: From: Barry Merrill ba...@mxg.com To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TRSMAIN Date: Wed, 21 Aug 2013 19:39:31 -0500 It's an easy JCL exercise to conduct an experiment to confirm what happens: TRSMAIN/AMATERSE will read a truncated tersed file and never detect it was truncated. I copied a 105472 byte valid tersed file into a DISP=(,CATLG,CATLG),SPACE=(TRK,(1)). The original untersed to 360,480 bytes, while the truncated file untersed to only 48152, and there was no message nor warning that the input file was short. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, August 21, 2013 5:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TRSMAIN On 21 August 2013 14:59, Richard Pinion rpin...@netscape.com wrote: A data set is compressed using TRSMAIN on z/OS. It is transmitted, using binary format, to a non-z/OS server. For whatever reason the compressed file on the server is incomplete. When the compressed file is transmitted, using binary format, back to a z/OS system, and uncompressed, will TRSMAIN know the data set is incomplete? Depends on what you mean by incomplete. A TRSMAIN/AMATERSE compressed data stream consists of a short header, and then 12-bit units with a value from 1 to 4096, terminated by a unit of zeros. The header does not contain an overall length field. (There is also a trailer, but I'm not sure it's used for anything.) If decompression hits EOF before seeing that ending zero unit, it should complain, though I don't know how elegantly. So if your data is truncated, it can and should be detected. But if you restore your damaged data into an FB dataset, the last block may be zero padded regardless, so a silent failure seems quite possible. If your compressed stream is missing a chunk in the middle, it's possible - and with anything bigger than a very small dataset, even likely - that what remains is decodable, but after the gap it certainly won't decode into anything much like the original. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN _ Netscape. Just the Net You Need. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
I did not wish to deprecate the [appropriate] use of catalog aliases. Once, long ago, there was a configuration of the linkage editor called IEWL440 that operated very sedately but used little [then real], storage to do its job. In one shop, call it S to protect the guilty, the applications programmers were very reluctant, perhaps for sentimental reasons, to give up using it long after any rationale for doing so had disappeared. Making IEWL440 an alias for a more storage-intensive and much more efficient version of the linkage editor resolved this problem without discommoding the these sentimental S applications programmers. This is a wholly appropriate use of catalog aliases. These uses are few but not for that reason unimportant. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TRSMAIN
On Wed, 21 Aug 2013 19:39:31 -0500, Barry Merrill wrote: It's an easy JCL exercise to conduct an experiment to confirm what happens: TRSMAIN/AMATERSE will read a truncated tersed file and never detect it was truncated. Checksum is your friend. Here's how to generate one using standard z/OS utilities: user@MVS:130$ cp //'sys1.maclib(splevel)' /dev/fd/1 | cksum 317904754 29808 cksum is a POSIX utility, so the checksum can be verified on any other UNIXy system; perhaps even on Windows with Cygwin, available at a very attractive price. I copied a 105472 byte valid tersed file into a DISP=(,CATLG,CATLG),SPACE=(TRK,(1)). The original untersed to 360,480 bytes, while the truncated file untersed to only 48152, and there was no message nor warning that the input file was short. I am dismayed to find among IBM VM download instructions at: http://www.vm.ibm.com/download/ the suggestion: PIPE fn VMARC A | fblock 80 00 | fn VMARC A F 80 where the 00 means pad any short record with nulls. I have repeatedly railed against this: the null padding is less likely to repair a transmission error than to conceal it, to be encountered later in the proces, at greater expense. I'm routinely outvoted with the specious argument that in those cases where the truncated characters were nulls or irrelevant the process will (seem to) work and the programer is spared the effort of diagnosing and repairing the process flaw and re-transmitting. I'm unsympathetic. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
On 8/21/2013 10:21 PM, John Gilmore wrote: In one shop, call it S to protect the guilty, the applications programmers were very reluctant, perhaps for sentimental reasons, to give up using it long after any rationale for doing so had disappeared. Making IEWL440 an alias for a more storage-intensive and much more efficient version of the linkage editor resolved this problem without discommoding the these sentimental S applications programmers. That brings back memories; we used a program named ZLKD from SHARE, credited to Alan Fulford of ALLIED BREWERIES, BURTON, 25/7/73 . While the original was written for MFT, picking up the partition size, it was easily converted to MVT. It checked the available storage, built a modified PARM with the appropriate SIZE parameter, and invoked the largest Linkage Editor that would fit. Our unprivileged users never had a chance to mess up g Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
