date:20130814

Look also at the IBM utility program AMBLIST.

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: What is the procedure to protect the MCS consoles?

2013-08-14 Thread R.S.

W dniu 2013-08-14 10:28, Victor Hugo Ochoa Avila pisze:

Hello everyone.
A question.
What is the procedure to protect the MCS consoles?
I need to protect consoles with RACF, and allow access to a particular group
support.

1. Protect resources, not tools. Console is rather tool than resource.
The resource is operator command. You should protect the commands using
OPERCMDS class profiles. Note, not only MVS commands are to be
protected, also JES commands and other subsystems (SDSF, RACF, DB2, MQ).

2. See CONSOLxx member, parameter LOGON(REQUIRED). With this value one
has to logon on the console in order to issue any further command. Other
options are AUTO (logged-off console has it's own default user), or
OPTIONAL - in this case logged-off console has no control in OPERCMDS
class. That means the console should be physically protected (if such
setting is approved at all).

3. For consoles attached to OSA-ICC or 2074, in other words, connected
via IP network, you have to secure the network, which means network
activities like router filters, etc. Out of mainframe activities. Note
the console traffic is not encrypted, including passwords and it could
be sniffed.

4. There is also CONSOLE class in RACF. In general, it's similar to
TERMINAL class, as it controls who can use given console, by its name.
IMHO I see no big reason why JSMITH could use CONS1, but not CONS2.
Note, the other security means, including OPERCMDS still apply. The
interesting option her could be conditinal access to OPERCMDS resources
with WHEN(CONSOLE(consname)) - for that you have to activate CONSOLE
class, even with ** UACC(READ) profile.

--
Radoslaw Skorupka
Lodz, Poland

--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88.
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.

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

Re: What is the procedure to protect the MCS consoles?

2013-08-14 Thread Binyamin Dissen

On Wed, 14 Aug 2013 03:28:40 -0500 Victor Hugo Ochoa Avila
vhoa@gmail.com wrote:

:Hello everyone.
:A question.
:What is the procedure to protect the MCS consoles?
:I need to protect consoles with RACF, and allow access to a particular group 
support.

CONSOLxx
 DEFAULT LOGON(REQUIRED)

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: load module scan

2013-08-14 Thread Elardus Engelbrecht

John Gilmore wrote:

Look also at the IBM utility program AMBLIST.

Unless I missed something obvious, I believe AMBLIST shows the binder 
options/results of options, not COBOL compiler options.

However I know some compiler options are propagated to binder unless it is 
overriden.

Perhaps could you be kind to tell us where in the output of AMBLIST are the 
COBOL compiler options shown?

Just curious of course if you don't mind, please.

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: z/TPF question

I have found that the use of z/OS facilities in configuring z/TPF can
now in fact be avoided, although other, less satisfactory external
ones must be used instead.

The original context of Dr Johnson's celebrated observation---He was
comparing a woman preaching to a dog walking on its hind legs---is
sexist, but that observation itself,

It is not done well, but one is surprised to find it done at all,

is appropriate here.   The HLASM is one of the glories of the
mainframe; and its avoidance is, at best, perverse.

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: load module scan

What AMBLIST does, and all it does, is make IDRs (IDentification
Records)---They are generated by the binder in response to IDENTIFY
statements in its input stream---available.

If a compiler propagates information about the options that were used
in a compilation, AMBLIST makes it available.  If not, not.

Most current IBM translators do propagate this information, together
with a product identification, version and modification level, and
translation date;  and the binder does the same thing for itself

What I should perhaps have mentioned in my original post is that these
IDRs are different for load modules and program objects.  Multiple
IDRs for a CSECT, RSECT or COMMON section are not supported for load
modules.  They are supported for program objects.  User data may be at
most 40 bytes in length in load-module CSECT IDRs and at most 80 bytes
in length in program-object CSECT IDRs.

Worth noting while I am in pedagogue mode is that users are free to
generate IDRs too, one for each load-module CSECT and many of them for
each program-object CSECT.

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: load module scan

2013-08-14 Thread Elardus Engelbrecht

John Gilmore wrote:

What AMBLIST does, and all it does, is make IDRs (IDentification 
Records)---They are generated by the binder in response to IDENTIFY statements 
in its input stream---available.

This I know. Whew! :-D

If a compiler propagates information about the options that were used in a 
compilation, AMBLIST makes it available.  If not, not.

Ok. This is that obvious thing I forgot. So I think the OP may or may not see 
the compiler options.

Most current IBM translators do propagate this information, together with a 
product identification, version and modification level, and translation date;  
and the binder does the same thing for itself

Indeed. Very handy for debugging purposes.

Thanks for your kind reply!

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: MVS ROUTE command is a bad influence on DB2 ERLY code

2013-08-14 Thread Walt Farrell

On Tue, 13 Aug 2013 19:17:49 -0400, Peter Relson rel...@us.ibm.com wrote:

Route does little more than send the command to another system. On that
system that command may be processed by some number of system address
spaces (such as master, consoles). Each will use whatever its lnklst is.

I don't know by what mechanism DB2 sees commands. -DB2T,REFRESH,EARLY is
not shorthand for a modify command (right?), so the command is routed to
the SSI (from the system address space) and will run with the lnklst of
that space.

So if you're seeing something old, then that space has not run with an
updated LNKLST. And indeed you showed that the LNKLST UPDATE was done only
for the DB2 spaces.

The LNKLST UPDATE was done only for the DB2 spaces, Peter, but there is one 
difference. We don't quite have all the info, but I'm going to make a guess 
that the OP is using SDSF to issue the commands, as he mentioned that his TSO 
logon was using the new LNKLST, too. If a TSO user issues an SVC 34 to issue 
the command -DB2T,REFRESH,EARLY, and it's picked up by the SSI, which space 
does it execute in?

You said the command is routed to the SSI (from the system address space) but 
did you assume there that the command was issued from an MCS console, and thus 
processed in the CONSOLE system address space? What happens when the command is 
issued in a TSO session? 

Since the TSO session was using the new LNKLST we seem to have some evidence 
that the command ran in the TSO session when executed directly, vs running in 
the CONSOLE address space (with the old LNKLST) when executed via ROUTE from 
the other system.

-- 
Walt

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

Re: load module scan

2013-08-14 Thread Doug

File Manager has some nice loadmod functions if you have it..

Sent from my iPhone

On Aug 14, 2013, at 7:51, Elardus Engelbrecht elardus.engelbre...@sita.co.za 
wrote:

 John Gilmore wrote:
 
 What AMBLIST does, and all it does, is make IDRs (IDentification 
 Records)---They are generated by the binder in response to IDENTIFY 
 statements in its input stream---available.
 
 This I know. Whew! :-D
 
 If a compiler propagates information about the options that were used in a 
 compilation, AMBLIST makes it available.  If not, not.
 
 Ok. This is that obvious thing I forgot. So I think the OP may or may not see 
 the compiler options.
 
 Most current IBM translators do propagate this information, together with a 
 product identification, version and modification level, and translation 
 date;  and the binder does the same thing for itself
 
 Indeed. Very handy for debugging purposes.
 
 Thanks for your kind reply!
 
 Groete / Greetings
 Elardus Engelbrecht
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Rexx Compile

2013-08-14 Thread Dr. Rick Williams

 
I was wondering, would anyone out there have the necessary JCL required to
compile an link a rexx routine?  
 
Thanks! 
 
Dr. Rick Williams

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

Re: load module scan

2013-08-14 Thread Farley, Peter x23353

And more importantly CBT file 321, COBANAL, which does a passable job of 
extracting the COBOL options directly from the load module code.

IIRC File 330 only provides an ISPF skin for COBANAL and not COBANAL itself.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Itschak Mugzach
Sent: Wednesday, August 14, 2013 4:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: load module scan

see file 330 on cbttape.org.

ITschak

On Wed, Aug 14, 2013 at 10:52 AM, Ron Thomas ron5...@gmail.com wrote:

 Hello.  From the load module i need to get all compiler options that is
 used to build the code(cobol.db2). Pls some one let us know is there any
 standard routines to get this information?


 Thanks,
 Ron T
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: load module scan

2013-08-14 Thread John P Kalinich

snip from COBANAL output

 Options in effect
--
 ADV QUOTE   DATA(31)  NODECK   NODUMP  NODYNAMNOFASTSRT
LIB LIST
 MAP NONUM   OBJ   NOOFFSET OPTIMIZE   OUTDD(Supplied)
NUMPROC(NOPFD)  NORENT
 RES SEQ SIZE(MAX) SOURCE   NOSSRANGE  NOTERM NOTEST
TRUNC(STD)  NOWORD
 NOVBREF XREFZWB   NONAME   NUMCLS(PRIM)  DBCS
AWO NOEVENTS
 NOCURRENCY  Compilation unit = Program
 RMODE(ANY)  NO TEST(STMT)  NO TEST(PATH)  NO TEST(BLOCK)
NOOPT OR OPT(STD)
 INTDATE(ANSI)   NO TEST(SEPARATE)  NOT PGMNAME(LONGUPPER)
NOT PGMNAME(LONGMIXED)
 NODLL   NOEXPORTALLNODATEPROC YEARWINDOW(1900)
ARITH(COMPAT)   NOTHREAD
 TEST(NOEJPNOC   NOSQL NOCICS   NOMDECKSQLCCSID   NOOPTFILE
XMLPARSE(COMPAT)
 CODEPAGE(1140)


Regards,
John K

Peter Farley of the IBM Mainframe Discussion List
IBM-MAIN@listserv.ua.edu wrote on 08/14/2013 09:01:57 AM:

 And more importantly CBT file 321, COBANAL, which does a passable
 job of extracting the COBOL options directly from the load module code.

 IIRC File 330 only provides an ISPF skin for COBANAL and not COBANAL
itself.

 HTH

 Peter

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
 ] On Behalf Of Itschak Mugzach
 Sent: Wednesday, August 14, 2013 4:22 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: load module scan

 see file 330 on cbttape.org.

 ITschak

 On Wed, Aug 14, 2013 at 10:52 AM, Ron Thomas ron5...@gmail.com wrote:

  Hello.  From the load module i need to get all compiler options that is
  used to build the code(cobol.db2). Pls some one let us know is there
any
  standard routines to get this information?
 
 
  Thanks,
  Ron T
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: load module scan

2013-08-14 Thread Schumacher, Otto

There is a product call EDGE Profolio Analysis that supports load modules.  The 
product only supported modules stored in PDS's.  The last time I used the 
product did not support PDSE's.  The product was not expensive but I do not 
know the current price for the product.

Regards
Otto H Schumacher
Transaction and Database Systems - CICS Specialist
U. S. Mainframe 
HP Enterprise Services 
Telephone +1 864 987 1417 
Mobile +1 864 569 5338 
Email otto.schumac...@hp.com 

  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Wednesday, August 14, 2013 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: load module scan

And more importantly CBT file 321, COBANAL, which does a passable job of 
extracting the COBOL options directly from the load module code.

IIRC File 330 only provides an ISPF skin for COBANAL and not COBANAL itself.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Itschak Mugzach
Sent: Wednesday, August 14, 2013 4:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: load module scan

see file 330 on cbttape.org.

ITschak

On Wed, Aug 14, 2013 at 10:52 AM, Ron Thomas ron5...@gmail.com wrote:

 Hello.  From the load module i need to get all compiler options that 
 is used to build the code(cobol.db2). Pls some one let us know is 
 there any standard routines to get this information?


 Thanks,
 Ron T
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

segment question

2013-08-14 Thread Crabtree, Anne D

I have an ETR in on this, but I have a feeling that person helping me is west 
coast!  I work 6am-2pm EDT and was hoping for answer today!  Thought I would 
seek help from all you VM experts.

While trying to apply maintenance on vm 6.2, I got the following error:
SV:VMFP2P1965E The command, CP SEND BLDSEG EXEC VMFBLD PPF SEGBLD
ESASEGS
SV:SEGBLIST HELPSEG.SEGMENT LINK (ALL NOLOG, failed
with
SV:return code
8

IBM responded:

The most likely problem is that your HELP segment will no longer fit
in the space allocated for it.  Please look for HELPSEG PSEGMAP and/or
HELP LSEGMAP on the D (51D) disk to see there is an error description
there.
  If that is the case you can use VMFSGMAP to expand the space. The
best suggestion would be to move the starting address on the DEFPARMS
from C00 to B00.  The DEFPARMS value would be:
  Old:
DEFPARMS...:  C00-CFF SR
  New:
DEFPARMS...:  B00-CFF SR
.
Once you complet this change (assuming that was the problem), you can
restart PUT2PROD.


So, I issued vmfsgmap segbld esasegs segblist and see the following:

Meg 000-MB  001-MB  002-MB  003-MB
St NameTyp 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
M ZCMS SYS W-W-1...2...3...
M GCS  SYS W---1...2...3...
M CMS  SYS W-W-1...2...3...

Meg 004-MB  005-MB  006-MB  007-MB
St NameTyp 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
M GCS  SYS WNNN6...7...

Meg 008-MB  009-MB  00A-MB  00B-MB
St NameTyp 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
  DOSBAM   SPA 8...9...A...
  CMSBAM   MEM 8...9...A...
  CMSDOS   MEM 8...9...A...R...
  DOSINST  DCS 8...R---A...B...
  SCEE DCS 8...A...B...

Meg 00C-MB  00D-MB  00E-MB  00F-MB
St NameTyp 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
  HELPSEG  DCS D...E...F...
M ZCMS SYS C...D...E...RRR
M CMS  SYS C...D...E...RRR

= 16-MB Line ==

I see how to change C00 to B00, but I have no idea how to read this map to make 
sure I don't clobber something else.

Any insight would be appreciated.  Thanks!

Anne D. Crabtree
System Programmer
WV Office of Technology Data Center
1900 Kanawha Blvd East
Bldg 6, Room B-110
Charleston, WV  25305
(304)558-5914 ext 58292
(304)558-1441 fax


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

Re: Rexx Compile

2013-08-14 Thread Thomas Berg

This should work I think (simple example!):

//REXXCOMP  EXEC  PGM=REXXCOMP,
// PARM='SLINE(AUTO),NOCEXEC,DLINK,PRINT,SOURCE,XREF' 
//*  =
//STEPLIB   DDDISP=SHR,DSN=REXX.SFANLMD  REXX COMPILER LOAD LIB 
//SYSIN DDDISP=SHR,DSN=sourcelib(name) 
//SYSPRINT  DDSYSOUT=* 
//SYSTERM   DDSYSOUT=* 
//SYSDUMP   DDDUMMY
//SYSCEXEC  DDDUMMY  NOT USING CEXEC OPTION HERE
//SYSPUNCH  DDDSN=OBJECT,DISP=(,PASS),   
//   SPACE=(800,(8000,1000))   
//*
//LKED  EXEC  PGM=HEWL,
// PARM='LIST,AMODE=31,RMODE=ANY,REUS,XREF,MAP'
//SYSLINDDDISP=(OLD,PASS),DSN=OBJECT 
//SYSLIBDDDISP=SHR,DSN=REXX.SEAGLMD  REXX COMPILER LOAD LIB 2   
//SYSPRINT  DDSYSOUT=* 
//SYSLMOD   DDDISP=SHR,DSN=loadlib(name)   



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)


 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of Dr. Rick Williams
 Sent: Wednesday, August 14, 2013 3:02 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Rexx Compile
 
   I was wondering, would anyone out there have the necessary JCL
 required to
 compile an link a rexx routine? Thanks!Dr. Rick Williams
 
 --
 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

New SHARE Blog Post - Live from Boston

2013-08-14 Thread Ed Jaffe

SHARE MVS Core Technologies Project Manager Mary Anne Matyaz takes a few 
minutes out of her busy schedule to blog about the outstanding 
conference going on here in Boston...


http://www.share.org/p/bl/et/blogid=9blogaid=247

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Rexx Compile

2013-08-14 Thread Dr. Rick Williams

Thank you sir!! 
 
 
Dr. Rick Williams
---Original Message---
 
From: Thomas Berg
Date: 8/14/2013 11:16:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rexx Compile
 
This should work I think (simple example!):
 
//REXXCOMP  EXEC  PGM=REXXCOMP,
// PARM='SLINE(AUTO),NOCEXEC,DLINK,PRINT,SOURCE,XREF'
//*  =
//STEPLIB   DDDISP=SHR,DSN=REXX.SFANLMD  REXX COMPILER LOAD LIB
//SYSIN DDDISP=SHR,DSN=sourcelib(name)
//SYSPRINT  DDSYSOUT=*
//SYSTERM   DDSYSOUT=*
//SYSDUMP   DDDUMMY
//SYSCEXEC  DDDUMMY  NOT USING CEXEC OPTION HERE
//SYSPUNCH  DDDSN=OBJECT,DISP=(,PASS),
//   SPACE=(800,(8000,1000))
//*
//LKED  EXEC  PGM=HEWL,
// PARM='LIST,AMODE=31,RMODE=ANY,REUS,XREF,MAP'
//SYSLINDDDISP=(OLD,PASS),DSN=OBJECT
//SYSLIBDDDISP=SHR,DSN=REXX.SEAGLMD  REXX COMPILER LOAD LIB 2
//SYSPRINT  DDSYSOUT=*
//SYSLMOD   DDDISP=SHR,DSN=loadlib(name)
 
 
 
Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
 
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of Dr. Rick Williams
 Sent: Wednesday, August 14, 2013 3:02 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Rexx Compile

   I was wondering, would anyone out there have the necessary JCL
 required to
 compile an link a rexx routine? Thanks!Dr. Rick Williams

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

ca - reclaim for hsm, rmm, cdses (and ucats??)

2013-08-14 Thread Michael Bieganski

Hello,  we just upgraded our last lpar to zos 1.13 so now have the option
of utilizing the ca-reclaim option. As of now, it is not defined in our
parmlib so is dormant.   I have both an rmm cds and an hsm bcds reorg
necessary in the upcoming months and was wondering if anyone has experience
yet with
ca-reclaim with rmm and/or hsm cdses.any gotchas???
Also, I know that once we turn that on via setsms or parmlib, all vsam
files on the system could be affected (I know we can expressly do an
alter noreclaimca).   Any suggestions where one would explicitly want to
set noreclaimca to avoid more problems than reclaim fixes?
(for example, we unfortunately have a number of user-catalogs that still
have 'imbed'  and theres no chance I'll be given any outages to
reorg the ucats to get rid of the imbed feature.I was wondering if
perhaps ucats with imbed dont play nicely with reclaim??)
thanks

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

Re: ca - reclaim for hsm, rmm, cdses (and ucats??)

2013-08-14 Thread Staller, Allan

ISTR that CA-RECLAIM was a z/OS 1.12 feature.

At any rate, I have been using this for DFHSM cds's and all other VSAM KSDS's 
since shortly after I converted to z/OS 1.13 in 03/2012 w/no issues (I skipped 
z/OS 1.12).
It seems to work as advertised, drastically reducing the frequency of CDS 
re-orgs. Can't speak to the RMM CDS's or UCAT's w/IMBED/REPLICATE.

I would not exclude anything, until an issue has been identified.

HTH,

snip
Hello,  we just upgraded our last lpar to zos 1.13 so now have the option of 
utilizing the ca-reclaim option. As of now, it is not defined in our
parmlib so is dormant.   I have both an rmm cds and an hsm bcds reorg
necessary in the upcoming months and was wondering if anyone has experience yet 
with ca-reclaim with rmm and/or hsm cdses.any gotchas???
Also, I know that once we turn that on via setsms or parmlib, all vsam files on 
the system could be affected (I know we can expressly do an
alter noreclaimca).   Any suggestions where one would explicitly want to
set noreclaimca to avoid more problems than reclaim fixes?
(for example, we unfortunately have a number of user-catalogs that still have 
'imbed'  and theres no chance I'll be given any outages to reorg the ucats to 
get rid of the imbed feature.I was wondering if perhaps ucats with imbed 
dont play nicely with reclaim??) thanks
/snip

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

How to diagnose 2F3

2013-08-14 Thread Patrick Roehl

In developing a new TCP/IP application I am causing our z/OS system to crash
and I don't know how to determine the cause.  The only clue I can find is in
the output for the job that was running, which shows an S2F3 abend code.
After re-IPLing, the JES console shows typical application messages and then
the beginning of the IPL sequence.

Using application debugging to a file (opening and closing for each write) I
have determined that the program, a client TCP/IP application, has issued a
write() of roughly 16K bytes, a shutdown(), and issued a read().  The read()
request is successful, but as I wait on the ECB for the read to complete,
the crash occurs.

Hint: The crash only occurs if the read() request times out.  Forcing a
delay in the server's response such that the read() times out reliably
causes the crash.  When no delay is introduced, the read() is successful and
everything runs normally.  The length of the delay  has no impact as long as
it times out (e.g. 10 second delay with an 8 second timeout or a 120 second
delay with a 115 second timeout).

This is a zPDT system running z/OS 1.10, however, I get identical results on
our zPDT 1.13 system (load module transfer - no re-assembly).

Where can I look for clues?

Thanks for any insight you can share.

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

Re: MVS ROUTE command is a bad influence on DB2 ERLY code

2013-08-14 Thread Jim Mooney

It's surprising to me that simply routing the command causes 
a different linklst to be used (guessing the old one). 


It should be surprising. It is not possible.


With all due respect and my humble thanks for your input, for the record, this 
is an inaccurate blanket statement. Someone may see this and not read the rest 
of your update, which goes on to explain how it *IS* possible. 


-Jim

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

Re: MVS ROUTE command is a bad influence on DB2 ERLY code

2013-08-14 Thread Jim Mooney

...I'm going to make a guess that the OP is using SDSF to issue the commands

Yes, all commands were done in SDSF. 

-Jim

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

Re: How to diagnose 2F3

2013-08-14 Thread Jim Mulder

 In developing a new TCP/IP application I am causing our z/OS system to 
crash
 and I don't know how to determine the cause.  The only clue I can find 
is in
 the output for the job that was running, which shows an S2F3 abend code.
 After re-IPLing, the JES console shows typical application messages and 
then
 the beginning of the IPL sequence.
 
 Using application debugging to a file (opening and closing for each 
write) I
 have determined that the program, a client TCP/IP application, has 
issued a
 write() of roughly 16K bytes, a shutdown(), and issued a read().  The 
read()
 request is successful, but as I wait on the ECB for the read to 
complete,
 the crash occurs.
 
 Hint: The crash only occurs if the read() request times out.  Forcing a
 delay in the server's response such that the read() times out reliably
 causes the crash.  When no delay is introduced, the read() is successful 
and
 everything runs normally.  The length of the delay  has no impact as 
long as
 it times out (e.g. 10 second delay with an 8 second timeout or a 120 
second
 delay with a 115 second timeout).
 
 This is a zPDT system running z/OS 1.10, however, I get identical 
results on
 our zPDT 1.13 system (load module transfer - no re-assembly).

*
From MVS System Codes:

   2F3
Explanation: One of the following has occurred to a job which was 
journaled
  or was otherwise eligible for restart (checkpoint/restart, step restart,
  or job restart): 

The job was running when a system failure occurred, and a system restart 
(IPL and JES2 WARM start) was performed. 

The initiator the job was running in terminated at End Of Memory (EOM). 

A system job queue entry for the job existed at the time of the failure, 
but the specific step to be restarted at was not eligible for restart. 
**

  This means that the 2F3 is merely a symptom of your system crash,
not the cause.  To determine the cause, you would want to start 
by taking a standalone dump. 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

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

CICS ACF2 z/OS Systems Programmer at The University of Chicago

2013-08-14 Thread Todd Last

The University of Chicago will soon be posting a position for a z/OS Systems 
Programmer with a minimum 10+ years of experience in CICS and ACF2 installation 
and administration.  

Todd Last
Team Lead, Mainframe Systems
The University of Chicago
Chicago, IL  60613
tl...@uchicago.edu

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

Re: C issue - 'struct stat'

Bernd wrote
shortening the functions' names to 8, upper case characters, COBOL API, etc.

I suggest you consider adding #pragma maps for the long function names;
if you do this, you don't need to change nothing else.


The distribution to classic z/OS is PDS oriented and I was specifically asked 
to continue that way (I may do parallel USS oriented distro).  Any fonction 
that is a file, becomes a member... 8 characters, upper case, period.  If I 
tell the users to use long, mixed case names, they may do it in COBOL with some 
compile time parameters... if their sysprog allows them to do it (doubtful).  
Those who want to do so, may call the internal functions by their long names.  
For all others, I created an API module.
ZA

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

Re: C issue - 'struct stat'

It is very late in the day to introduce a new PDS as opposed to PDSE
library of this sort.

Moreover, while PDSE members must have at most eight-character
principal names they may have long aliases.

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: C issue - 'struct stat'

bernd wrote
Normally, if you compile C sources you got from somewhere on z/OS
using the more classical compiler options, this is no problem, unless you
have external function names that are longer than 8 characters and that
don't differ in their first 8 characters, and for such situations, 
#pragma map
is the perfect solution. For example:

#ifdef XML_PRAGMA

#pragma map (xml_alloc, XMLXALLO)
#pragma map (xml_free , XMLXFREE)

I did not know about this pragma.  While it would not help me with the need to 
shorten file names, it wiould have helped otherwise.  I will look into it.
Thanks
ZA

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

Re: C issue - 'struct stat'

It is very late in the day to introduce a new PDS as opposed to PDSE
library of this sort.


The loadlib and some other libraries are indeed PDSE (I used the word PDS 
loosly)
ZA

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

PDSE (was: C issue - 'struct stat')

On Wed, 14 Aug 2013 15:57:31 -0400, John Gilmore wrote:

It is very late in the day to introduce a new PDS as opposed to PDSE
library of this sort.
 
It can be environmentally dictated.  In our lab we have more systems
at more releases (some unsupported, but you know how customers
are) than parallel sysplex supports.  And the sharing incapabilities of
PDSE outside sysplex are dreadful.  We have a lot of PDS, some very
new.

Moreover, while PDSE members must have at most eight-character
principal names they may have long aliases.

Strange rule; I wonder why.  Might it reflect a restriction of command
syntax of utilities, such as IEBCOPY?  ISPF?  Hmmm...

//STEP  EXEC  PGM='Long-PDSE-alias-name',...

Never mind.

-- gil

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

Re: MVS ROUTE command is a bad influence on DB2 ERLY code

2013-08-14 Thread Shmuel Metz (Seymour J.)

In
of5b623f4f.38249aee-on85257bc6.007f6049-85257bc6.00800...@us.ibm.com,
on 08/13/2013
   at 07:17 PM, Peter Relson rel...@us.ibm.com said:

It's surprising to me that simply routing the command causes 
a different linklst to be used (guessing the old one).

It should be surprising. It is not possible.

That depends on what it is. If the command is processed in a
different address space depending on whether it is routed, then the
active link lists might differ.

BTW, is a command issued via the CONSOLE command processed in the
requesting address space or is the SVC 34 issued in the Communications
Task?

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

Re: Coping Unix files

2013-08-14 Thread Shmuel Metz (Seymour J.)

In 7806785360373454.wa.paulgboulderaim@listserv.ua.edu, on
08/13/2013
   at 03:47 PM, Paul Gilmartin paulgboul...@aim.com said:

I believe SYSPROC, SYSOUT, SYSPRINT, and SYSIN are superfluous.

They are in this case. SYSPROC and SYSEXEC are only needed if you
invoke command procedures (CLIST, REXX) from them. SYSIN, SYSOUT and
SYSPRINT are only needed if you invoke a utility that requires them.

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

Re: C issue - 'struct stat'

Excellent!  Making them PDSEs will decomplicate your life.

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: C issue - 'struct stat'

Excellent!  Making them PDSEs will decomplicate your life.

No, it won't. PDSEs are fine and easier to work with then PDSs

My main issues were 

There is no easy way to load members to a library that is defined VB, 255 
(IEBUPDTE did not work on that best).  I guess I could have used individual 
steps of IEBGENER.  Instead I wrote an ADDMEM utility in Rexx.  All other PDS 
or PDSE manipulation was done using IEBUPDTE or ISPF.

Shortening the file names to 8 bytes, upper case consistently in all source 
code was the core of my port process, but it was done with some Perl scripts.  

The other core issue was to resolve bind time dependencies.  Here I had had the 
worst headache!  I will leave the explanation of my solution out for now until 
I am ready to publish my process. 

ZA

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

Re: z/OS 1.13 Last date to order ServerPac

2013-08-14 Thread Tom Wasik

This is where I go to get end of service/end of marketing dates:
http://www-03.ibm.com/systems/z/os/zos/support/zos_eos_dates.html

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

Re: C issue - 'struct stat'

The scheme you have outlined will certainly do the job.  It is perhaps
more labor-intensive than it needs to be.

Recall that while a PDSE member name may be at most 8 of the usual
characters in length, an alias of such a member name may be at most
1024 characters in length from an enlarged character set.  If then you
have a routine name R that is immediately usable as a PDSE member
name, you use it.

If R is not immediately usable you

1) mangle it to obtain from it a usable PDSE member name M, use M as
the member name and

2) specify that  R is an alias of M.

This scheme also works mutatis mutandis for routines that have
multiple entry points E0, E1, . . .; but you have said nothing about
such a requirement.

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: C issue - 'struct stat'

On Wed, 14 Aug 2013 17:14:16 -0500, Ze'ev Atlas wrote:

Excellent!  Making them PDSEs will decomplicate your life.

No, it won't. PDSEs are fine and easier to work with then PDSs

My main issues were 

There is no easy way to load members to a library that is defined VB, 255 
(IEBUPDTE did not work on that best).  I guess I could have used individual 
steps of IEBGENER.  Instead I wrote an ADDMEM utility in Rexx.  All other PDS 
or PDSE manipulation was done using IEBUPDTE or ISPF.

Shortening the file names to 8 bytes, upper case consistently in all source 
code was the core of my port process, but it was done with some Perl scripts.  

The other core issue was to resolve bind time dependencies.  Here I had had 
the worst headache!  I will leave the explanation of my solution out for now 
until I am ready to publish my process. 
 
You fail to appreciate how much making them UNIX directories could
have decomplicated your life.  I suspect one of the Dovetailed utilities
could let you do a local spawn of a UNIX executable using the unneutered
names and propagating DDNAMES.  (Or perhaps BPXWUNIX if you eschew
third-party utilities.)

BTW, when you added PDS capability, etc. to PCRE, I hope you didn't
do that at the expense of disabling UNIX directory capability.

-- gil

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

Re: C issue - 'struct stat'

John Gilmore said:
Recall that while a PDSE member name may be at most 8 of the usual
characters in length, an alias of such a member name may be at most
1024 characters in length from an enlarged character set.  If then you
have a routine name R that is immediately usable as a PDSE member
name, you use it.

Very interesting suggestion.  I will certainly look into it

Thanks
ZA

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

Re: C issue - 'struct stat'

Paul Gilmartin said:
You fail to appreciate how much making them UNIX directories could
have decomplicated your life.  I suspect one of the Dovetailed utilities
could let you do a local spawn of a UNIX executable using the unneutered
names and propagating DDNAMES.  (Or perhaps BPXWUNIX if you eschew
third-party utilities.)

No, I don't fail to appreciate this and I've said that I will look into it.  
The issue is my poor customers who are confined to the Classic z/OS with all 
what is coming with it, and who are limited by their sysprogs in whatever they 
can or cannot do (up to the point of not having any say in what compiler option 
they could or could not use in their COBOL applications.)  For them, I will 
stick with PDS and PDSE.  There was at least one person on this forum who had 
expressed such sentiments and I myself worked in such environments.

BTW, when you added PDS capability, etc. to PCRE, I hope you didn't
do that at the expense of disabling UNIX directory capability.

Please don't underestimate me.  You are invited to download my distro and look 
for yourself.  If it is a PDS or PDSE, I deal with it, otherwise, I pretty much 
continue with the existing code, especially, if it is HFS, I continue with the 
regular Unix directory related existing code.

The current version does not (yet) support file name patterns.  There was a 
limit to my patient for developing new features and I had to decide when to 
freeze the release.

ZA

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

Re: C issue - 'struct stat'

2013-08-14 Thread Ted MacNEIL

are limited by their sysprogs in whatever they can or cannot do (up to the 
point of not having any say in what compiler option they could or could not 
use in their COBOL applications.)  

Their SYSPROGs have too much power!
Applications Programmers are there to facilitate the business.
So are SYSPROGs!
Which means they facilitate apps.
NOT set arbitrary rules!
-
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: C issue - 'struct stat'

2013-08-14 Thread David Crayford


On 15/08/2013 11:04 AM, Ted MacNEIL wrote:

are limited by their sysprogs in whatever they can or cannot do (up to the 
point of not having any say in what compiler option they could or could not use 
in their COBOL applications.)

Their SYSPROGs have too much power!
Applications Programmers are there to facilitate the business.
So are SYSPROGs!
Which means they facilitate apps.
NOT set arbitrary rules!


Well said! I've been lucky in that I've never worked at a customer site 
which had such stupid rules. In fact it's always been the other way round
where the application folks had the power. SYSPROGs and service delivery 
were seen as money spenders, not money makers.



-
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


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

Re: C issue - 'struct stat'

On Thu, 15 Aug 2013 03:04:35 +, Ted MacNEIL wrote:

are limited by their sysprogs in whatever they can or cannot do (up to the 
point of not having any say in what compiler option they could or could not 
use in their COBOL applications.)

Their SYSPROGs have too much power!
Applications Programmers are there to facilitate the business.
So are SYSPROGs!
Which means they facilitate apps.
NOT set arbitrary rules!
  
I've been on the other side of that one, doing development tools
support.  For our project, we agreed that our code should be
reusable, reentrant, refreshable, running in its own address
space, loaded from an authorized library into a nonmodifiable
subpool.  Each developer could do his own coding and unit
testing, but I was charged with the tools for integration.  So
I made RENT the uniform PARM for assembler, and
REUS/RENT/REFR for link editing.

Then _one_ developer writing a stand-alone utility chose to make
it non-renterable.  Not for any functional reason, but only because
he chose not to obtain RSA and working storage because It wasn't
necessary.  I seethed and added the flexibility to our development
tools to support one developer's one load module.  He cost me more
in the support effort than he saved by not coding a GETMAIN.

-- gil

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

Re: C issue - 'struct stat'

2013-08-14 Thread Ted MacNEIL

I understand.
But, that's why there are standards.
You backed down when you shouldn't have.

My complaint is the dictatorial SYSPROG.
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: Paul Gilmartin paulgboul...@aim.com
Sender:   IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Date: Thu, 15 Aug 2013 00:16:14 
To: IBM-MAIN@LISTSERV.UA.EDU
Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C issue - 'struct stat'

On Thu, 15 Aug 2013 03:04:35 +, Ted MacNEIL wrote:

are limited by their sysprogs in whatever they can or cannot do (up to the 
point of not having any say in what compiler option they could or could not 
use in their COBOL applications.)

Their SYSPROGs have too much power!
Applications Programmers are there to facilitate the business.
So are SYSPROGs!
Which means they facilitate apps.
NOT set arbitrary rules!
  
I've been on the other side of that one, doing development tools
support.  For our project, we agreed that our code should be
reusable, reentrant, refreshable, running in its own address
space, loaded from an authorized library into a nonmodifiable
subpool.  Each developer could do his own coding and unit
testing, but I was charged with the tools for integration.  So
I made RENT the uniform PARM for assembler, and
REUS/RENT/REFR for link editing.

Then _one_ developer writing a stand-alone utility chose to make
it non-renterable.  Not for any functional reason, but only because
he chose not to obtain RSA and working storage because It wasn't
necessary.  I seethed and added the flexibility to our development
tools to support one developer's one load module.  He cost me more
in the support effort than he saved by not coding a GETMAIN.

-- 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: C issue - 'struct stat'