HCD HiperSockets problem

[Stuart Willis]

Hi All

I'm trying to set up HiperSockets on our Z9 A02 and running Z/VM VERSION 5 
RELEASE 3.0, SERVICE LEVEL 0701 and ADCD ZOS 1.10 running as a guest 
under VM. 

I'm using Redbook HiperSockets Implementation Guide March 2007.

When I try to define IQD Page 26 Add Channel Path I get error message
   +---
   | Channel path type IQD is not supported by channel path ID F4. |
   +---

I have tried other Path ID's but still get the same error!

Regards
Stuart.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: dead zone

[Shane]

On Tue, 2010-01-05 at 08:45 -0600, Mohammad Khan wrote:

> In other words more lipstick is being applied here. When are they going to 
> realize that it's a pig ?

Hard to argue ... :-))

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: What happened to Eric Loriaux' web site

[Elardus Engelbrecht]

Sam Golob wrote:

>Does anyone know what happened to Eric Loriaux' web site?  It doesn't seem 
to be there anymore.

I did a quick check, but both sites http://phpnuke.loriaux.com/

and http://www.ping.be/~ping1475/ are unavailable or DSN unresolved...

This very OLD one is working: http://www.ping.be/~ping1475/adds.html 

Google came up with references by other people/sites to his website, but 
addresses are the same as stated above...

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: dead zone

[Bob Shannon]

>> In other words more lipstick is being applied here. When are they going to 
>> realize that it's a pig ?

>Hard to argue ... :-))

So what's your alternative? Abandon Java on Z?

Bob Shannon
Rocket Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: useless message at IPL

[Peter Relson]

Could you please be more explicit about the message you did see, and 
possibly about the messages you eventually found in the hardcopy log 
(SYSLOG)?

You wrote
>But when NIP was waiting for my reply, I could not see what was wrong so 
that I could fix it

What message was it waiting for you to reply to?

It's almost certain that the messages were written via WTO, not WTL. They 
probably specified MCSFLG of HARDCPY. If these were ASAxxxI messages, it's 
possible that the invoker did not take advantage of some infrastructure 
support that would avoid using hardcopy-only during IPL for precisely the 
case you encountered. After IPL, hardcopy-only is used to avoid flooding 
the console, since the syslog can be examined. A change to take advantage 
of this could likely be made in a future release.

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HCD HiperSockets problem

[Mark Pace]

IIRC - the first Hipersocket channel must be FF, then FE, etc.


On Wed, Jan 6, 2010 at 6:28 AM, Stuart Willis wrote:

> Hi All
>
> I'm trying to set up HiperSockets on our Z9 A02 and running Z/VM VERSION 5
> RELEASE 3.0, SERVICE LEVEL 0701 and ADCD ZOS 1.10 running as a guest
> under VM.
>
> I'm using Redbook HiperSockets Implementation Guide March 2007.
>
> When I try to define IQD Page 26 Add Channel Path I get error message
>   +---
>   | Channel path type IQD is not supported by channel path ID F4. |
>   +---
>
> I have tried other Path ID's but still get the same error!
>
> Regards
> Stuart.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Mark Pace
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HCD HiperSockets problem

[Stuart Willis]

I have tried FF FE get the same   

+---+
| Channel path type IQD is not supported by channel path ID FF. |
+---+
  

Stuart.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Mark Pace
Sent: 06 January 2010 13:14
To: IBM-MAIN@bama.ua.edu
Subject: Re: HCD HiperSockets problem

IIRC - the first Hipersocket channel must be FF, then FE, etc.


On Wed, Jan 6, 2010 at 6:28 AM, Stuart Willis
wrote:

> Hi All
>
> I'm trying to set up HiperSockets on our Z9 A02 and running Z/VM
VERSION 5
> RELEASE 3.0, SERVICE LEVEL 0701 and ADCD ZOS 1.10 running as a guest
> under VM.
>
> I'm using Redbook HiperSockets Implementation Guide March 2007.
>
> When I try to define IQD Page 26 Add Channel Path I get error message
>   +---
>   | Channel path type IQD is not supported by channel path ID F4. |
>   +---
>
> I have tried other Path ID's but still get the same error!
>
> Regards
> Stuart.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Mark Pace
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HCD HiperSockets problem

[Mark Pace]

Here is the definition from my HCD.


Processor ID . . . . : Z9
Configuration mode . : LPAR
Channel Subsystem ID : 0

Channel path ID  . . . . : FF   PCHID  . . . . . :
Channel path type  . . . : IQD
Operation mode . . . . . : SHR
Managed  . . . . . . . . : No   I/O Cluster  . . :

Description  . . . . . . :

Dynamic entry switch ID  :
Entry switch ID  . . . . :
Entry port . . . . . . . :

Maximum frame size
in KB  . . . . . . : 64


On Wed, Jan 6, 2010 at 8:29 AM, Stuart Willis wrote:

> I have tried FF FE get the same
>
> +---+
> | Channel path type IQD is not supported by channel path ID FF. |
> +---+
>
>
> Stuart.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Mark Pace
> Sent: 06 January 2010 13:14
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: HCD HiperSockets problem
>
> IIRC - the first Hipersocket channel must be FF, then FE, etc.
>
>
> On Wed, Jan 6, 2010 at 6:28 AM, Stuart Willis
> wrote:
>
> > Hi All
> >
> > I'm trying to set up HiperSockets on our Z9 A02 and running Z/VM
> VERSION 5
> > RELEASE 3.0, SERVICE LEVEL 0701 and ADCD ZOS 1.10 running as a guest
> > under VM.
> >
> > I'm using Redbook HiperSockets Implementation Guide March 2007.
> >
> > When I try to define IQD Page 26 Add Channel Path I get error message
> >   +---
> >   | Channel path type IQD is not supported by channel path ID F4. |
> >   +---
> >
> > I have tried other Path ID's but still get the same error!
> >
> > Regards
> > Stuart.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
>
>
>
> --
> Mark Pace
> Mainline Information Systems
> 1700 Summit Lake Drive
> Tallahassee, FL. 32317
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Mark Pace
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HCD HiperSockets problem

[Bruce Hewson]

Hello Stuart,

I use "0F" and "7F" for my IQD chpids.

I usually use "F*" and "*F" for my ICP chpids. 
(legacy...ESCON 16 port cards only had 15 usable chpids...so last *F chpid 
unused.)

But I haven't tried using FF.

But this is on a z10does your z9 actually support IQD chpids??

On Wed, 6 Jan 2010 13:29:41 -, Stuart Willis 
 wrote:

>I have tried FF FE get the same
>
>+---+
>| Channel path type IQD is not supported by channel path ID FF. |
>+---+
>
>
>Stuart.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>Behalf Of Mark Pace
>Sent: 06 January 2010 13:14
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: HCD HiperSockets problem
>
>IIRC - the first Hipersocket channel must be FF, then FE, etc.
>
>
>On Wed, Jan 6, 2010 at 6:28 AM, Stuart Willis
>wrote:
>
>> Hi All
>>
>> I'm trying to set up HiperSockets on our Z9 A02 and running Z/VM
>VERSION 5
>> RELEASE 3.0, SERVICE LEVEL 0701 and ADCD ZOS 1.10 running as a guest
>> under VM.
>>
>> I'm using Redbook HiperSockets Implementation Guide March 2007.
>>
>> When I try to define IQD Page 26 Add Channel Path I get error message
>>   +---
>>   | Channel path type IQD is not supported by channel path ID F4. |
>>   +---
>>
>> I have tried other Path ID's but still get the same error!
>>
>> Regards
>> Stuart.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>>
>
>
>
>--
>Mark Pace
>Mainline Information Systems
>1700 Summit Lake Drive
>Tallahassee, FL. 32317
>


Regards
Bruce Hewson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HCD HiperSockets problem

[R.S.]

There is no requirement for HiperSocket chipd.
I use any (unused) number I want.

--
Radoslaw Skorupka
Lodz, Poland



Stuart Willis pisze:
I have tried FF FE get the same   

+---+
| Channel path type IQD is not supported by channel path ID FF. |
+---+
  

Stuart.


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Mark Pace
Sent: 06 January 2010 13:14
To: IBM-MAIN@bama.ua.edu
Subject: Re: HCD HiperSockets problem

IIRC - the first Hipersocket channel must be FF, then FE, etc.


On Wed, Jan 6, 2010 at 6:28 AM, Stuart Willis
wrote:


Hi All

I'm trying to set up HiperSockets on our Z9 A02 and running Z/VM

VERSION 5

RELEASE 3.0, SERVICE LEVEL 0701 and ADCD ZOS 1.10 running as a guest
under VM.

I'm using Redbook HiperSockets Implementation Guide March 2007.

When I try to define IQD Page 26 Add Channel Path I get error message
  +---
  | Channel path type IQD is not supported by channel path ID F4. |
  +---

I have tried other Path ID's but still get the same error!

Regards
Stuart.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html









--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HCD HiperSockets problem

[Bruce Hewson]

Hi Stuart,

Pressing F1 do you get an extended help message?

On Wed, 6 Jan 2010 05:28:44 -0600, Stuart Willis 
 wrote:


>   +---
>   | Channel path type IQD is not supported by channel path ID F4. |
>   +---

>
>Regards
>Stuart.
>

Regards
Bruce Hewson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: useless message at IPL

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Peter Relson
> Sent: Wednesday, January 06, 2010 6:55 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: useless message at IPL
> 

> 
> What message was it waiting for you to reply to?
> 
> It's almost certain that the messages were written via WTO, 
> not WTL. They 
> probably specified MCSFLG of HARDCPY. If these were ASAxxxI 
> messages, it's 
> possible that the invoker did not take advantage of some 
> infrastructure 
> support that would avoid using hardcopy-only during IPL for 
> precisely the 
> case you encountered. After IPL, hardcopy-only is used to 
> avoid flooding 
> the console, since the syslog can be examined. A change to 
> take advantage 
> of this could likely be made in a future release.
> 
> Peter Relson
> z/OS Core Technology Design

Unfortunately, I don't have the SYSLOG from that IPL. The message being waited 
upon was one which said that I need to reply with an OMVS= which contained 
BPXPRMnn members which did not have any syntax errors. I knew the old PARMLIB 
BPXPRMnn suffix values and so reply with them. This allowed z/OS to continue to 
IPL. I then looked at the SYSLOG to see what I did wrong and fix it. I then 
IPL'ed again. If the BPXPRMnn syntax errors had been shown, I could have fixed 
them on another system and simply replied with same member suffixes and thus 
avoided a second IPL. OK, not a big deal. However, if I had done an "update in 
place" of the PARMLIB member, I wouldn't have had a way to continue the IPL. So 
I would have had to try to figure out the error on another system with no help. 
I guess what it really means is that I should never update an in-use member of 
PARMLIB, but copy it to a different suffix, modify it, then point to the 
modified PARMLIB member. 

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCI and Auditors perceptions thereof

[Peter Vander Woude]

Don,

   If your firewall folks just recently upgraded the firewall, it could be that 
the 
upgrade "defaulted", or reset some configuration settings.  For FTPS, the 
firewall cannot do what's referred to as "stateful checking".  I know ours does 
that, and if it does that on the control connection (and/or data connection), 
you will see the error you've been getting.  

On another note, someone mentioned earlier in the thread about PCI-DSS 
and it's requirements for NATing, but also asked about what PCI-DSS means 
by "public network".  PCI-DSS uses that term to indicate any network where 
someone from outside your company might gain access to your internal 
network, and be able access the credit/debit card information, as in the case 
of a company setting up a wireless network.  In the wireless network example, 
that initially means setting up firewalls between that wireless router and the 
systems that process the credti/debit transactions.

  Also, I believe someone mentioned that PCI-DSS requires that the credit card 
information (i.e. PAN) be encrypted inflight.  Unless I'm mistaken, PCI-DSS 
only 
deals with data at rest (i.e. in databases, or flat files). Encryption of this 
data 
inflight is not part of the PCI-DSS standard, yet.  If it were, then some of 
the 
breaches in recent time, where transactions were caught inflight, even while a 
company may have passed a PCI audit, should not have happened.  If PCI-
DSS does require the PAN to be encrypted, it would also have to require that 
the track-2 data also be encrypted.

Peter

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HCD HiperSockets problem

[Stuart Willis]

Hi Bruce 

I did that it tells me that the device is not supported on the system
but if If display supported devices it tells me IQD is supported?

+--- Supported Control Units
---+ 
|Row 1 of 134 More:   >
| 
| Command ===> _ Scroll ===> PAGE
| 
|
| 
| Select a control unit to view the list of device types that can be
| 
| attached to the control unit.
| 
|
| 
|   ---Default for---
| 
|   Control Unit  Supported Protocol  I/O Concurrency
| 
|   Type  Protocols Used  Level
| 
|   AFP1  D,S,S4S 2
| 
|   CTC   D D 2
| 
|   DUMMY D,S,S4D 2
| 
|   FCP
| 
|   FCTC  2
| 
|   IQD
| 
|   NOCHECK   D,S,S4S 2
| 
|   OSA
| 
|   OSC
| 
|   OSN
| 
|   RS6K  D,S,S4S42
| 
|  F1=Help   F2=Split  F3=Exit   F7=Backward   F8=Forward
| 
|  F9=Swap  F12=CancelF20=Right F22=Command
| 
+---
+ 
 


Stuart.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Bruce Hewson
Sent: 06 January 2010 13:55
To: IBM-MAIN@bama.ua.edu
Subject: Re: HCD HiperSockets problem

Hi Stuart,

Pressing F1 do you get an extended help message?

On Wed, 6 Jan 2010 05:28:44 -0600, Stuart Willis 
 wrote:


>   +---
>   | Channel path type IQD is not supported by channel path ID F4. |
>   +---

>
>Regards
>Stuart.
>

Regards
Bruce Hewson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OSA Express3 questions

[R.S.]

Bruce Hewson pisze:
[...]
> i.e.   2 PCHID == 2 CHPID, and 2 CU per CHPID as CUADD=0 and 1.


Bruce,
You cannot do it. Dot.
Caution! For OSD chpid type you can define multiple CUs (using CUADD), 
but all of them are tied to CHPID, not the port!
Multiple CUs are needed only if you want to have many TCP/IP stacks - in 
this case you need >255 devices.


Assuming you don't plan to use a lot of TCP/IP stacks there is no 
problem with CUs and devices: you can use separate set of *devices* for 
each port. Both sets of devices are defined in the same CU, but it 
shoudn't hurt.


HTH
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: useless message at IPL

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of McKown, John
> 
> [ snip ] . . . I guess what it really
> means is that I should never update an in-use member of PARMLIB, but
copy it to a different suffix,
> modify it, then point to the modified PARMLIB member.

That's how a lot of wisdom is acquired -- one "slap" at a time.  :-)

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where have the control blocks gone?

[Don Poitras]

Clark Morris wrote:
> 
> On 5 Jan 2010 09:54:17 -0800, in bit.listserv.ibm-main you wrote:
> 
> >Clark Morris wrote:
> >>
> >> On 5 Jan 2010 07:17:48 -0800, in bit.listserv.ibm-main you wrote:
> >>
> >> >Mike Myers wrote:
> >> >>
> >> >> Steve:
> >> >>
> >> >>
> >> >> I do know that the formatter in IPCS (TCBEXIT IECDAFMT - at least I
> >> >> think that's the right exit - if not, then it's probably IECIOFMT) will
> >> >> display the DCB as a block of data, but does not format its fields 
> >> >> either.
> >> >>
> >> >> Mike Myers
> >> >
> >> >IP SUMM FORMAT will display DCB info, here's the one for SYSMDUMP:
> >> >
> >> >DATA MANAGEMENT,CONTROL BLOCKS FOR OPEN DATA SETS
> >> >***DCB,AT LOCATION 7ADF68   (BSAM)
> >> >  DASD
> >> >+0   ,  DCBE  7F424B7C KEYCN 00 FDAD  00 076F0005 02DVTBA 
> >> >EF6026
> >> >+10  ,  KEYLE 00  DEVT 2F  TRBAL 184E   BUFCB 0001  BUFL    DSORG 
> >> >4000  IOBAD 0050C000
> >> >+20  ,  EODAD 8601 RECFM 98 EXLST 7ADFC4TIOT 048C   MACRF 
> >> >0020  IFLGS 00 DEBA  7B516C
> >> >+30  ,  OFLGS 92   BEEA68  OPTCD 00   E00908IOBL 0A  SYNA 
> >> >01CIND     BLKSI 6180
> >> >+40  ,  WCPO  30013030 IOBA  0050C070 NCP 04   EOBRA D79658  EOBW 
> >> >00D79658  DIRCT    LRECL 1040
> >> >+54  ,  POINT 0001
> >>
> >> The LE forms of SYSUDUMP (may be CEEDUMP, my memory is bad), have some
> >> very useful formatting and make at least COBOL debugging much easier.
> >
> >I can't think of anything offhand that you can't get from:
> >
> > IP VERBX LEDATA
> 
> Isn't that using SYSMDUMP and IPCS?  I'm talking about the dumps
> available to most applications programmers.

There's nothing stopping any programmer changing his JCL from:
//SYSUDUMP to
//SYSMDUMP

There is a learning curve, but if looking at dumps is something you do
for a living, it's worth the effort. I avoided it for years because I
couldn't see the benefit, but now I just groan when somebody hands me a
huge SYSUDUMP.

-- 
Don Poitras - zSeries R & D  -  SAS Institute Inc. -  SAS Campus Drive 
mailto:sas...@sas.com   (919)531-5637  Fax:677- Cary, NC 27513

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where have the control blocks gone?

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Don Poitras
Sent: Wednesday, January 06, 2010 8:44 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Where have the control blocks gone?


There's nothing stopping any programmer changing his JCL from:
//SYSUDUMP to
//SYSMDUMP

There is a learning curve, but if looking at dumps is something you do
for a living, it's worth the effort. I avoided it for years because I
couldn't see the benefit, but now I just groan when somebody hands me a
huge SYSUDUMP.


I've been following this thread off and on. There is a caveat to the
SYSMDUMP that I think needs to be recognized (and if someone has a way
around it, I'm all eyes, ears or whatever).

SDUMP[X] knowledgeable programs, or programs with error recovery
routines:  When you use SYSMDUMP, the last dump written clobbers what
went before.

That is the gotcha you have to be willing to accept. If the last dump
allows you to determine what the root cause is... 

Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: useless message at IPL

[John Kelly]

It should be noted that early IPL messages can be written to the HMC 
system console in addition to/or instead of the z/OS NIP console. While 
the HMC 
system console has a number of usability problems, it does allow scrolling 
backward to see messages.


I'll bite, how do you make NIP/IPL messages go to the HMC console in 
addition to the NIP console? The only that I've been able to use the HMC 
console to trace back messages is if I IPL from it and HARDCOPY only has 
SYSLOG and OPERLOG as DEVNUM.

Jack Kelly
202-502-2390 (Office)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OSA Express3 questions

[Ed Finnell]

 
In a message dated 1/6/2010 8:42:15 A.M. Central Standard Time,  
r.skoru...@bremultibank.com.pl writes:

You cannot do it. Dot.
Caution! For OSD chpid type you can  define multiple CUs (using CUADD), 
but all of them are tied to CHPID, not  the port!
Multiple CUs are needed only if you want to have many TCP/IP  stacks - in 
this case you need >255 devices.


>>
Most of this should be covered in the SAPR  with the z10. Only one session  
from Denver SHARE has reference to OSA  Express. 2217 Software 
Considerations for z10 migration.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: useless message at IPL

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Kelly
> Sent: Wednesday, January 06, 2010 9:21 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: useless message at IPL
> 
> 
> It should be noted that early IPL messages can be written to the HMC 
> system console in addition to/or instead of the z/OS NIP 
> console. While 
> the HMC 
> system console has a number of usability problems, it does 
> allow scrolling 
> backward to see messages.
> 
> 
> I'll bite, how do you make NIP/IPL messages go to the HMC console in 
> addition to the NIP console? The only that I've been able to 
> use the HMC 
> console to trace back messages is if I IPL from it and 
> HARDCOPY only has 
> SYSLOG and OPERLOG as DEVNUM.
> 
> Jack Kelly
> 202-502-2390 (Office)
On my sandox, I created another system configuration with no NIP consoles. And 
I created another LOADnn member to use that system configuration. So all the 
IPL/NIP message go to my HMC console now. This is only for my testing. Once I'm 
finished, the sandbox will be IPL'ed as normal. 

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

New cut of the CBT Tape - V478

[Sam Golob]

Hi Folks,

   If you go to www.cbttape.org, I've straightened out the CBT 
directory and the Updates directory so things are less confusing.  The 
CBT directory now contains the contents of Version 478 of the CBT Tape, 
cut on Dec 27, 2009.  The Updates directory now contains updated files 
that were contributed since then.  This is the way it is "supposed to 
be".  There might be a few odds and ends that still need fixing, such as 
the DFDSS and FDR backups of the CBT tape datasets on a DASD volume.  
I'll try to update those when I can.


   Xephon materials are now available on the CBT Tape site 
(www.cbttape.org) at URL www.cbttape.org/xephon.  If you missed this 
URL, it is now available on the CBT page of www.cbttape.org.   Also, 
File 814 now contains articles from many back "MVS Update" issues, 
dating back to the 1980s.  For MVS Update articles, the only year not 
(thus far) covered, is 1997.  www.cbttape.org/xephon covers 1998-2005 
entire magazines ("PDF protections" and some of the copyright notices 
have been removed).  Please stay tuned about later articles.  I have to 
ask Thomas Publications if they want to release any of them yet.


   Since Thomas Publications has stopped publishing the Xephon 
magazines, they gave the support rights for the software programs to 
www.cbttape.org, so (I think) the Disclaimer Section of CBT Tape File 
001 (and the Disclaimer on the www.cbttape.org web site) should now 
apply to the Xephon materials that Thomas Publications has released to 
us (as of May 2008).


   All the best of everything to all of you.

Sincerely,  Sam Golob

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 360 programs on a z/10

[Howard Brazee]

On Tue, 05 Jan 2010 18:52:59 -0500, Walter Bushell 
wrote:

>> They weren't really beaten, either. They ran out of fuel, food and
>> ammo.
>
>That constitutes being beaten.

Logistics is a major, major component of warfare.

And business.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL replaced by Jol: - Was Why is JCL so bad

[Howard Brazee]

On 5 Jan 2010 14:08:59 -0800, pgil...@pc-link.com.au (Paul Gillis)
wrote:

>I used Jol from 1970 through 1988 and was very happy with it, then  
>when I changed jobs I had to relearn JCL. Jol certainly provided much  
>of what has been discussed here since the early 70s.
>Never tried a parm greater than 100 bytes, wonder if that would work.  
>Probably no reason why it couldn't if the target program was able to  
>cope with it.

I used a beta version of an Amdahl operating system called Aspen,
running under VM.It was powerful and programmers loved it.But
it sometimes had performance problems - after all it was beta.

I don't know if it was IBM that wanted to stick with JCL.   IBM seemed
to want to go more Rexx.But customers seemed more resistant to
change even than IBM. Too bad, as the mind set isn't to consider
the power of IBM mainframes in these distributed Unix environments
companies are moving to.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: useless message at IPL

[Don Imbriale]

I have found command SETOMVS SYNTAXCHECK=(xx) to be useful when making
changes to BPXPRMxx members.

It checks syntax as well as the existence of HFS and zFS data sets specified
in the catalog. Mount points are not verified.
-- 
--
Don Imbriale

On Wed, Jan 6, 2010 at 9:04 AM, McKown, John
wrote:

> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Peter Relson
> > Sent: Wednesday, January 06, 2010 6:55 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: useless message at IPL
> >
> 
> >
> > What message was it waiting for you to reply to?
> >
> > It's almost certain that the messages were written via WTO,
> > not WTL. They
> > probably specified MCSFLG of HARDCPY. If these were ASAxxxI
> > messages, it's
> > possible that the invoker did not take advantage of some
> > infrastructure
> > support that would avoid using hardcopy-only during IPL for
> > precisely the
> > case you encountered. After IPL, hardcopy-only is used to
> > avoid flooding
> > the console, since the syslog can be examined. A change to
> > take advantage
> > of this could likely be made in a future release.
> >
> > Peter Relson
> > z/OS Core Technology Design
>
> Unfortunately, I don't have the SYSLOG from that IPL. The message being
> waited upon was one which said that I need to reply with an OMVS= which
> contained BPXPRMnn members which did not have any syntax errors. I knew the
> old PARMLIB BPXPRMnn suffix values and so reply with them. This allowed z/OS
> to continue to IPL. I then looked at the SYSLOG to see what I did wrong and
> fix it. I then IPL'ed again. If the BPXPRMnn syntax errors had been shown, I
> could have fixed them on another system and simply replied with same member
> suffixes and thus avoided a second IPL. OK, not a big deal. However, if I
> had done an "update in place" of the PARMLIB member, I wouldn't have had a
> way to continue the IPL. So I would have had to try to figure out the error
> on another system with no help. I guess what it really means is that I
> should never update an in-use member of PARMLIB, but copy it to a different
> suffix, modify it, then point to the modified PARMLIB member.
>
> --
> John McKown
> Systems Engineer IV
> IT
>
> Administrative Services Group
>
> HealthMarkets(r)
>
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone * (817)-961-6183 cell
> john.mck...@healthmarkets.com * www.HealthMarkets.com
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCI and Auditors perceptions thereof

[Donald Russell]

On Wed, Jan 6, 2010 at 06:15, Peter Vander Woude wrote:

> Don,
>
>   If your firewall folks just recently upgraded the firewall, it could be
> that the
> upgrade "defaulted", or reset some configuration settings.  For FTPS, the
> firewall cannot do what's referred to as "stateful checking".  I know ours
> does
> that, and if it does that on the control connection (and/or data
> connection),
> you will see the error you've been getting.
>
>
That appears to be what happened I'll know for sure next week when the
firewall people make the change to allow FTPS.

For me, the red herring was that regular FTP works fine, which, to me, begs
the question: What's the point of blocking FTPS without blocking FTP?

Thanks for all the discussion and feedback...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

How long does an I/O take (very roughly)?

[Hunkeler Peter (KIUP 4)]

Hi,
I'm about to update a chart I'm using to illustrate the
relative speed of various actions like CP cycle, storage
access, etc.

Does it still hold true that an I/O from controller cache (cache 
hit) takes about 1ms and and I/O from the platter (cache miss) 
takes about 5ms. All I want is two very rough figures. I don't
want to consider different hardware or attachement types.

--
Peter Hunkeler
CREDIT SUISSE AG

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where have the control blocks gone?

[Farley, Peter x23353]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Thompson, Steve
> Sent: Wednesday, January 06, 2010 10:08 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Where have the control blocks gone?
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Don Poitras
> Sent: Wednesday, January 06, 2010 8:44 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Where have the control blocks gone?
> 
> 
> There's nothing stopping any programmer changing his JCL from:
> //SYSUDUMP to
> //SYSMDUMP
> 
> There is a learning curve, but if looking at dumps is something you do
> for a living, it's worth the effort. I avoided it for years because I
> couldn't see the benefit, but now I just groan when somebody hands me
a
> huge SYSUDUMP.
> 
> 
> I've been following this thread off and on. There is a caveat to the
> SYSMDUMP that I think needs to be recognized (and if someone has a way
> around it, I'm all eyes, ears or whatever).
> 
> SDUMP[X] knowledgeable programs, or programs with error recovery
> routines:  When you use SYSMDUMP, the last dump written clobbers what
> went before.
> 
> That is the gotcha you have to be willing to accept. If the last dump
> allows you to determine what the root cause is... 

Which may not be the case with COBOL internal sorts, where the SORT also
abends after the original abend occurs in an input or output procedure.

And not every site makes IPCS readily available to ordinary programmers,
even if they want to learn.

Peter


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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HCD HiperSockets problem

[Field, Alan C.]

Have you checked the processor definition? ISTR that on ours there are 2 
choices and whether IQD is supported is one of them

- Original Message -
From: IBM Mainframe Discussion List 
To: IBM-MAIN@bama.ua.edu 
Sent: Wed Jan 06 05:28:44 2010
Subject: HCD HiperSockets problem

Hi All

I'm trying to set up HiperSockets on our Z9 A02 and running Z/VM VERSION 5 
RELEASE 3.0, SERVICE LEVEL 0701 and ADCD ZOS 1.10 running as a guest 
under VM. 

I'm using Redbook HiperSockets Implementation Guide March 2007.

When I try to define IQD Page 26 Add Channel Path I get error message
   +---
   | Channel path type IQD is not supported by channel path ID F4. |
   +---

I have tried other Path ID's but still get the same error!

Regards
Stuart.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCI and Auditors perceptions thereof

[Shmuel Metz (Seymour J.)]

In , on
01/05/2010
   at 03:05 PM, Donald Russell  said:

>Is USS the same thing as "OMVS"?

Officially USS is Unformatted System Services, but many people
unofficially misuse the acronym to refer to Unix System Services. There's
also a distinction between using Unix System Services and logging on to
the Unix System Services shell. 

The acronym OMVS is a bit confusing because it refers both to Unix System
Services and to a specific address space.

>I'm told USS is not available on the others.

These days a lot of MVS software depends on Unix System Services, so I
suspect that what they mean is that you can't telnet to a Unix System
Services shell on those systems. However, they might mean that the
security data base doesn't have OMVS segments for normal users except on
one system.

>What I'd like to do is invoke sftp from a rexx clist

Rexx and CLIST are completely different animals.


In , on
01/05/2010
   at 04:12 PM, Donald Russell  said:

>It's not that OMVS isn't there, it's just we don't grant access to it
>regularly except on one of our MVS systems. I wonder why that is 
>I'm guessing it's money. :-)

There's no charge for enabling access to Unix System Services; my guess is
that they're not configured to share Unix file systems and don't want to
allocate separate home directories for each system.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 360 programs on a z/10

[Shmuel Metz (Seymour J.)]

In , on 01/05/2010
   at 05:57 PM, Clark Morris  said:

>Which then got fouled by DOS360 being substantially different from OS360.

To say nothing of a host of new lines announce *after* the S/360, e.g.,
S/3.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCI and Auditors perceptions thereof

[Shmuel Metz (Seymour J.)]

In , on
01/05/2010
   at 05:57 PM, "McKown, John"  said:

>Why not use BPXWUNIX to run a UNIX command in REXX?

That should work if he has an OMVS segement; my best guess is that he only
has it on one of his systems.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc

[Shmuel Metz (Seymour J.)]

In , on 01/04/2010
   at 05:43 PM, Paul Gilmartin  said:

>Does that mean before there were PROCs?  

No.

>PROCs are little use without symbols. 

They were quite useful.

>Or was everything done with overrides?

Yes. As I recall, symbolic parameters came in with OS/360 Release 14.

>For most of what I cited, JCL/initiator exploits it. 

The Initiator runs in Supervisor; Rexx does not.

>That suggests that something is in initiator that would more 
>properly be in allocation.

There's more to Allocation then SVC 99. What's missing is an unprivileged
interface to the Allocation features that are either global or that are
local but have no TU assigned.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where have the control blocks gone?

[Shmuel Metz (Seymour J.)]

In <4b42276c.90...@trainersfriend.com>, on 01/04/2010
   at 10:37 AM, Steve Comstock  said:

>* Instead of three (or more) SVRBs, there are only two

Under what circumstances did you see three SVRB's in the past? I'd expect
that for an ABEND in O/C/EOV, but not for an ABEND in application code.

>* When I force an abend right after OPEN the DCB does
>   not show up as formatted in the dump

The DEB should show up. AFAIK IBM never formatted the DCB in SYSUDUMP.
Were you thinking of SYSMDUMP viewed from IPCS?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Regina REXX under W/XP

[Shmuel Metz (Seymour J.)]

In , on
01/04/2010
   at 02:46 PM, "McKown, John"  said:

>Any chance that the file is UTF? If so, it might have a BOM (Byte Order
>Mark) as the first two (or 4) bytes of the file. 

The BOM might legitimately be present for UCS-2, UCS-4 or UTF-16, but not
for UTF-8.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Sun/STK Holddata No Longer Included With Cumulative Maintenance

[Shmuel Metz (Seymour J.)]

In , on 01/05/2010
   at 11:54 AM, Paul Gilmartin  said:

>o Issuing HOLDDATA is not syncronized with our test cycle which
>  drives our cumulative maintenance releases. 

Do you build your cum service with the then current HOLDDATA? If not, why
not. 

>o It's our understanding that many customers age corrective
>  service on the shelf before APPLYing -- let their peers be
>  early adopters.  Such customers would need to download HOLDDATA
>  separately after ageing the PTFs (unless they were naive enough
>  to be satisfied with stale HOLDDATA).

Protect your customers, but don't hobble them.

>It would help the first of these cases, but not the second, if we
>reissued the cumulative maintenance whenever there were new HOLDDATA 

I wouldn't expect, or want that, although there might be a case for
rebuilding the cum service when a fix for a PE became available.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why is JCL so bad?

[Shmuel Metz (Seymour J.)]

In , on 01/04/2010
   at 04:29 PM, john gilmore  said:

>JCL has been criticized by those who have not mastered it since the time
>of OS PCP.

ObQoheleth Similar complaints were no doubt made by my Uncle Crow and Aunt
Maggie.

>He begins here by attempting to distinguish a macro processor and a
>programming language, implying it would seem that a macro processor is
>not a programming language; but he then proceeds immediately to
>criticize, a little ungrammatically but unambiguously enough, both JCL
>and the HLASM as lacking two of the important attributes of programming
>languages, viz., "graceful branching" and "clean iteration".

If you compare the macro facilities of HLA and PL/I, you will be hard
pressed to justify the way that HLA does it as having "graceful branching"
and "clean iteration". Certainly AIF is better than nothing, but it is
crude.

>Someone unfamiliar with the HLASM macro language would find it
>unintelligible; and there is a familiar, now tedious perspective from
>which it is judged long-winded and/or detail-ridden; but there is
>nothing unclean about it.

This someone has been familiar with the syntax for more than 4 decades and
finds it unclean. OTOH, I'm not familiar with an assembler whose macro
language is any better.

>What distresses me about these views is not their substance, with which
>I expect usually to disagree.  It is his perspective. 

I can't really quarrel with that, but you also have a limited perspective.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: useless message at IPL

[Shmuel Metz (Seymour J.)]

In , on
01/05/2010
   at 10:51 AM, "McKown, John"  said:

>Like somebody has a 3287 printer any more? Or any printers?

Virtual 1403 under z/VM?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCI and Auditors perceptions thereof

[Paul Gilmartin]

On Wed, 6 Jan 2010 10:01:41 -0500, Shmuel Metz (Seymour J.) wrote:
>
>>What I'd like to do is invoke sftp from a rexx clist
>
>Rexx and CLIST are completely different animals.
>
Except that Rexx EXECs and CLISTs may be mingled in a single
SYSPROC library.  Magic Numbers.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Help with sysplex root filesystem.

[McKown, John]

I'm trying to go to the "sysplex root" filesystem set up. I'm getting the 
following messages:

BPXF008I FILE SYSTEM /dev 906
WAS NOT MOUNTED.
THE MOUNT POINT SPECIFIED IN BPXPRMF5 DOES NOT EXIST.

BPXF008I FILE SYSTEM OMVS.LIHT.ETC 907
WAS NOT MOUNTED.
THE MOUNT POINT SPECIFIED IN BPXPRMF5 DOES NOT EXIST.

The BPXPRMF5 member for these looks like:

MOUNT FILESYSTEM('/dev') /* TFS for /dev directory */
MOUNTPOINT('/&SYSNAME./dev')
TYPE(TFS) /* Filesystem type TFS */
MODE(RDWR) /* Mounted for read/write */
PARM('-s 4')
  NOAUTOMOVE


MOUNT FILESYSTEM('OMVS.&SYSNAME..ETC')
MOUNTPOINT('/&SYSNAME./etc')
   TYPE(HFS) MODE(RDWR)

The &SYSNAME is LIHT. I have used my old setup to mount the new sysplex root 
and version filesystem. I did an "ls -l" on those and the output matches the 
book.


John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Help with sysplex root filesystem.

[Mark Zelden]

On Wed, 6 Jan 2010 10:45:49 -0600, McKown, John
 wrote:

>I'm trying to go to the "sysplex root" filesystem set up. I'm getting the
following messages:
>
>BPXF008I FILE SYSTEM /dev 906
>WAS NOT MOUNTED.
>THE MOUNT POINT SPECIFIED IN BPXPRMF5 DOES NOT EXIST.
>
>BPXF008I FILE SYSTEM OMVS.LIHT.ETC 907
>WAS NOT MOUNTED.
>THE MOUNT POINT SPECIFIED IN BPXPRMF5 DOES NOT EXIST.
>
>The BPXPRMF5 member for these looks like:
>
>MOUNT FILESYSTEM('/dev') /* TFS for /dev directory */
>MOUNTPOINT('/&SYSNAME./dev')
>TYPE(TFS) /* Filesystem type TFS */
>MODE(RDWR) /* Mounted for read/write */
>PARM('-s 4')
>  NOAUTOMOVE
>
>
>MOUNT FILESYSTEM('OMVS.&SYSNAME..ETC')
>MOUNTPOINT('/&SYSNAME./etc')
>   TYPE(HFS) MODE(RDWR)
>
>The &SYSNAME is LIHT. I have used my old setup to mount the new sysplex
root and version filesystem. I did an "ls -l" on those and the output
matches the book.
>
>

Did you follow the procedure to create the system specific file system
and symbolic links?  Are the mounts for these file systems after
the mount of the system specific file system in BPXPRMxx? Do you
have SYSPLEX(YES) in BPXPRMxx?

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: useless message at IPL

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Don Imbriale
> Sent: Wednesday, January 06, 2010 10:01 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: useless message at IPL
> 
> I have found command SETOMVS SYNTAXCHECK=(xx) to be useful when making
> changes to BPXPRMxx members.
> 
> It checks syntax as well as the existence of HFS and zFS data 
> sets specified
> in the catalog. Mount points are not verified.
> -- 
> --
> Don Imbriale

Many, many thanks! 

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How long does an I/O take (very roughly)?

[Scott Rowe]

With a DS8300 Turbo, my overall average response time is around 1ms.  It looks 
to me like a cache hit is a little less than .5ms, with less than .300ms of 
connect time.

>>> "Hunkeler Peter (KIUP 4)"  1/6/2010 11:07 
>>> AM >>>
Hi,
I'm about to update a chart I'm using to illustrate the
relative speed of various actions like CP cycle, storage
access, etc.

Does it still hold true that an I/O from controller cache (cache 
hit) takes about 1ms and and I/O from the platter (cache miss) 
takes about 5ms. All I want is two very rough figures. I don't
want to consider different hardware or attachement types.

--
Peter Hunkeler
CREDIT SUISSE AG

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html 



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How long does an I/O take (very roughly)?

[Hal Merritt]

Ignoring a lot and oversimplifying, I believe that modern DASD should routinely 
deliver 0.1ms (hit) and 1ms (miss).   

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Hunkeler Peter (KIUP 4)
Sent: Wednesday, January 06, 2010 10:08 AM
To: IBM-MAIN@bama.ua.edu
Subject: How long does an I/O take (very roughly)?

Hi,
I'm about to update a chart I'm using to illustrate the
relative speed of various actions like CP cycle, storage
access, etc.

Does it still hold true that an I/O from controller cache (cache 
hit) takes about 1ms and and I/O from the platter (cache miss) 
takes about 5ms. All I want is two very rough figures. I don't
want to consider different hardware or attachement types.

--
Peter Hunkeler
CREDIT SUISSE AG

 
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HCD HiperSockets problem

[Mark Post]

>>> On 1/6/2010 at  6:28 AM, Stuart Willis  wrote: 
> Hi All
> 
> I'm trying to set up HiperSockets on our Z9 A02 and running Z/VM VERSION 5 
> RELEASE 3.0, SERVICE LEVEL 0701 and ADCD ZOS 1.10 running as a guest 
> under VM. 
> 
> I'm using Redbook HiperSockets Implementation Guide March 2007.
> 
> When I try to define IQD Page 26 Add Channel Path I get error message
>+---
>| Channel path type IQD is not supported by channel path ID F4. | 
>
>+---
> 
> I have tried other Path ID's but still get the same error!

Are you trying to specify already existing channel paths?  If so, don't.  Pick 
one that is not already defined and use that.


Mark Post

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Help with sysplex root filesystem.

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden
> Sent: Wednesday, January 06, 2010 10:57 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Help with sysplex root filesystem.
> 

> >
> 
> Did you follow the procedure to create the system specific file system
> and symbolic links?  Are the mounts for these file systems after
> the mount of the system specific file system in BPXPRMxx? Do you
> have SYSPLEX(YES) in BPXPRMxx?
> 
> Mark
> --

I used the two jobs in SYS1.SAMPLIB to make two new ZFS filesystems. One 
problem that I have which might be my problem, is that I need to use my 
original "root" filesystem in this environment. I simply don't have the DASD 
available to make a copy. So I use one new ZFS as the "Sysplex root file 
system". I use the other ZFS as the "System specific file system". I use my 
original root filesystem as the "Version file system".

But I just checked. The "Version file system" is supposed to have /dev, /tmp, 
/var, and /etc be symlinks to $SYSNAME/... . And "current root" does not. So I 
think I need to make that happen. Thanks for the thoughts!

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HCD HiperSockets problem

[Stuart Willis]

Hi Mark

No if I try and use one that is used it gives me another error message CU 
already used.  

Stuart.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: useless message at IPL

[Shmuel Metz (Seymour J.)]

In , on
01/05/2010
   at 04:11 PM, "McKown, John"  said:

>Yes, it did go to HARDCPY in the CONSOLnn member. Which is set to SYSLOG.
>Which is a SPOOL dataset. Which really means that these messages are kept
>somewhere until JES comes up.

If it's in a situation where you took a dump, you can retrieve the
messages from MTRACE.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: useless message at IPL

[Shmuel Metz (Seymour J.)]

In , on
01/06/2010
   at 08:04 AM, "McKown, John"  said:

>I guess what it really means is that I should never update an in-use
>member of PARMLIB, but copy it to a different suffix, modify it, then
>point to the modified PARMLIB member. 

Or use the PARMLIB syntax checker. Or both.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Help with sysplex root filesystem.

[Mark Zelden]

On Wed, 6 Jan 2010 11:18:55 -0600, McKown, John
 wrote:


>> --
>
>I used the two jobs in SYS1.SAMPLIB to make two new ZFS filesystems. One
problem that I have which might be my problem, is that I need to use my
original "root" filesystem in this environment. I simply don't have the DASD
available to make a copy. So I use one new ZFS as the "Sysplex root file
system". I use the other ZFS as the "System specific file system". I use my
original root filesystem as the "Version file system".
>

FYI... the same version root (sysres set) is shared between some systems
that have a unix shared file system configuration and some that don't here.
Nothing changes or needs to change in the version root.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HCD HiperSockets problem

[Neubert, Kevin]

During Add Channel Path do you get a different result using F4 (Prompt) for 
Channel Path ID and Channel Path Type?  In other words is Type IQD available in 
both instances?

Regards,

Kevin

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Stuart Willis
Sent: Wednesday, January 06, 2010 3:29 AM
To: IBM-MAIN@bama.ua.edu
Subject: HCD HiperSockets problem

Hi All

I'm trying to set up HiperSockets on our Z9 A02 and running Z/VM VERSION 5 
RELEASE 3.0, SERVICE LEVEL 0701 and ADCD ZOS 1.10 running as a guest 
under VM. 

I'm using Redbook HiperSockets Implementation Guide March 2007.

When I try to define IQD Page 26 Add Channel Path I get error message
   +---
   | Channel path type IQD is not supported by channel path ID F4. |
   +---

I have tried other Path ID's but still get the same error!

Regards
Stuart.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCI and Auditors perceptions thereof

[Donald Russell]

On Wed, Jan 6, 2010 at 07:01, Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net > wrote:

> In , on
> 01/05/2010
>at 03:05 PM, Donald Russell  said:
>
> >Is USS the same thing as "OMVS"?
>
> Officially USS is Unformatted System Services, but many people
> unofficially misuse the acronym to refer to Unix System Services. There's
> also a distinction between using Unix System Services and logging on to
> the Unix System Services shell.
>
> The acronym OMVS is a bit confusing because it refers both to Unix System
> Services and to a specific address space.
>
> >I'm told USS is not available on the others.
>
> These days a lot of MVS software depends on Unix System Services, so I
> suspect that what they mean is that you can't telnet to a Unix System
> Services shell on those systems. However, they might mean that the
> security data base doesn't have OMVS segments for normal users except on
> one system.
>
> >What I'd like to do is invoke sftp from a rexx clist
>
> Rexx and CLIST are completely different animals.
>


The idea I was trying to convey is I wanted to invoke an sftp file transfer
from a program invoked as if it were a TSO command. I figured everybody is
familiar with "clist" as a concept, rather than a specific language, and I
specified REXX because I don't write clist language code any more.

Which is the correct noun to refer to a program, read from SYSEXEC in a TSO
address space? In TSO land I generally refer to them as "clists" though
they're written in REXX. In VM/CMS land I call them "EXECs" even though they
are written in REXX, or EXEC 2 or EXEC. On zLinux I call them "scripts" or
"shell scripts" even though they may be written in REXX, php, bash shell,
korn shell, etc...




>
>
> In , on
> 01/05/2010
>at 04:12 PM, Donald Russell  said:
>
> >It's not that OMVS isn't there, it's just we don't grant access to it
> >regularly except on one of our MVS systems. I wonder why that is
> >I'm guessing it's money. :-)
>
> There's no charge for enabling access to Unix System Services; my guess is
> that they're not configured to share Unix file systems and don't want to
> allocate separate home directories for each system.
>
>

I suspect that's the reason...

I have a TSO ID on each of these different MVS systems, no sharing of files
between them, so I manually copy my rexx tools from one system to the others
with TSO TRANSMIT/RECEIVE... *I* wouldn't mind if I could access Unix System
Services even if the home directories were not shared... that's not much
different than what we do now with TSO access. (And if it really mattered I
could probably do something with rsync or similar)

I'll poke around and see what the response is like...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

HCD HiperSockets problem

[Jorge Arueira Campos]

*Example 3-1 IOCP statements for the z/OS environment*

*CHPID PATH=(CSS(1,2),F4),SHARED, **

*PARTITION=((CSS(1),(A12),(=)),(CSS(2),(A23,A24,A25),(=))**

*),TYPE=IQD*

*CHPID PATH=(CSS(1,2),F5),SHARED, **

*PARTITION=((CSS(1),(A12),(=)),(CSS(2),(A23,A24,A25),(=))**

*),TYPE=IQD*

*CHPID PATH=(CSS(1,2),F7),SHARED, **

*PARTITION=((CSS(1),(A12),(=)),(CSS(2),(A23,A24,A25),(=))**

*),TYPE=IQD*

*CNTLUNIT CUNUMBR=E800,PATH=((CSS(1),F4),(CSS(2),F4)),UNIT=IQD*

*IODEVICE ADDRESS=(E800,032),CUNUMBR=(E800),UNIT=IQD*

*CNTLUNIT CUNUMBR=E900,PATH=((CSS(1),F5),(CSS(2),F5)),UNIT=IQD*

*IODEVICE ADDRESS=(E900,032),CUNUMBR=(E900),UNIT=IQD*

*CNTLUNIT CUNUMBR=EB00,PATH=((CSS(1),F7),(CSS(2),F7)),UNIT=IQD*

*IODEVICE ADDRESS=(EB00,032),CUNUMBR=(EB00),UNIT=IQD*

**

*HIPERSOCKETS   *

* *

*CHANNEL PATH   *

* *

*  C0 IQD*

*C1 IQD*

*C2 IQD*

* *

*CONTROL  UNIT*

* *

*0C00   IQD*

*0C10   IQD*

*0C20  IQD*

* *

*DEVICES*

* *

*C000  (256)*

*C001  (256)*

*C002  (256)  *

* *

*C0C00C000*

*C1C10C100*

*C2C20C200*

*Renato Barnack
Analista de Suporte
Politec Global IT Services
TEL (55 0XX11) 3327 7427*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCI and Auditors perceptions thereof

[Kirk Wolf]

FWIW -  you should be able to run the sftp client from a z/OS userid
that has an OMVS segment, but has a read-only home directory shared by
multiple userids.   It seems unlikely to me that the Unix shell will
work this way, but I haven't tried it.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where have the control blocks gone?

[Don Poitras]

Thompson, Steve wrote:
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Don Poitras
> Sent: Wednesday, January 06, 2010 8:44 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Where have the control blocks gone?
> 
> 
> There's nothing stopping any programmer changing his JCL from:
> //SYSUDUMP to
> //SYSMDUMP
> 
> There is a learning curve, but if looking at dumps is something you do
> for a living, it's worth the effort. I avoided it for years because I
> couldn't see the benefit, but now I just groan when somebody hands me a
> huge SYSUDUMP.
> 
> 
> I've been following this thread off and on. There is a caveat to the
> SYSMDUMP that I think needs to be recognized (and if someone has a way
> around it, I'm all eyes, ears or whatever).
> 
> SDUMP[X] knowledgeable programs, or programs with error recovery
> routines:  When you use SYSMDUMP, the last dump written clobbers what
> went before.
> 
> That is the gotcha you have to be willing to accept. If the last dump
> allows you to determine what the root cause is... 

Use FREE=CLOSE on the SYSMDUMP DD.

-- 
Don Poitras - zSeries R & D  -  SAS Institute Inc. -  SAS Campus Drive 
mailto:sas...@sas.com   (919)531-5637  Fax:677- Cary, NC 27513

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

LNKLST & APF Help

[George Rodriguez]

This is a how to question. In the SYS1.PARMLIB(PROG00) member I have an
existing library that I really need to delete but I can't. Instead I
want to add a new entry in front of the one that's there now. As they
say a picture is worth a 1,000 word, so here's the net result of what I
want to do:

 

APF ADD DSNAME(OEM#P.CAI.EZT.R6M4.CAILIB)SMS  (this one
in front )

APF ADD DSNAME(OEM#T.CAI.CAILIB) SMS

 

And:

 

LNKLST ADD NAME(LNKLST00) DSN(OEM#P.CAI.EZT.R6M4.CAILIB)VOL(POEM01)
(this one in front)

LNKLST ADD NAME(LNKLST00) DSN(OEM#T.CAI.CAILIB) VOL(POEM00)

 

And I want to do it dynamically. For the APF it's just adding the entry
into PROG00 and issuing the SET PROG=XX command. I need to know if this
will work for the LNKLST?

 

LNKLST DEFINE NAME(LNKLST01) COPYFROM(CURRENT) 

LNKLST ADD NAME(LNKLST01) DSN(OEM#P.CAI.EZT.R6M4.CAILIB) VOL(POEM01)

LNKLST ADD NAME(LNKLST01) DSN(OEM#T.CAI.CAILIB)  VOL(POEM00)
<==<< this one to replace one that's there.

LNKLST ACTIVATE NAME(LNKLST01) 

 

The reason is that I need the R6M4 library to be read before the OEM#T
library.

 

Thanks in advance...

 

George Rodriguez

Specialist II - IT Solutions

Application Support / Quality Assurance

PX - 47652

(561) 357-7652 (office)

(561) 707-3496 (mobile)

School District of Palm Beach County

3348 Forest Hill Blvd.

Room B-332

West Palm Beach, FL. 33406-5869

Florida's Only A-Rated Urban District For Five Consecutive Years

 



--
--Palm Beach County Schools-

Rated "A" by the Florida Department of Education 2005-2009

-Home of Florida's first LEED Gold Certified School-
---http://www.palmbeachschools.org-

The District of Palm Beach County is an Equal Education Opportunity
Provider and Employer. Under Florida law, e-mail addresses are
public records. If you do not want your e-mail address released in
response to a public records request, do not send  electronic mail
to this entity. Instead, contact this office by phone or in
writing.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: dead zone

[Mohammad Khan]

No no no ... there is no suggestion / advice in my comment. Just an 
observation from a bemused observer on the latest installment in this effort. 
There was something called High Performance Compiler for Java in mid 90's 
IIRC.

Mohammad

On Wed, 6 Jan 2010 07:25:04 -0500, Bob Shannon 
 wrote:

>>> In other words more lipstick is being applied here. When are they going to
>>> realize that it's a pig ?
>
>>Hard to argue ... :-))
>
>So what's your alternative? Abandon Java on Z?
>
>Bob Shannon
>Rocket Software
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where have the control blocks gone? -- Now down in the dumps

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Don Poitras
Sent: Wednesday, January 06, 2010 12:10 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Where have the control blocks gone?



Use FREE=CLOSE on the SYSMDUMP DD.


That only works if you are not interested in any other ABEND or dump
producing event that occurs. 

If DISP=MOD would work for SYSMDUMP, I could figure out how to split the
dumps by processing the file with REXX or some such.

[I have a special case with my stuff -- the things I work on are
multi-threaded, multi-tasking and one failure may not be related at all
to another.]

Let me give you an example:  Program "DRIVER" is running. In a daughter
TCB a program is writing to DASD and gets an Sx37. Let's say that 10
seconds later, under a different TCB the program I am interested in
(SHUCKS) finally gets the S0C3 I set up. That's the dump I really want
to look at. 

But let's have even more fun. Before I can get to the dump DSN with
IEBGENER (which would have to be invoked within this JOBSTEP to deal
with the DISP=OLD...), another program under a different TCB ABENDS. I
just lost the dump I'm really interested in. In this case, my only
choice for this is a SLIP.

So the SYSMDUMP just can't handle this level of complexity. 

Welcome to the world of a developer. Thankfully, I have the ability to
issue MVS commands and can set SLIPs when and as I need them. 

But for the typical programmer/analyst in a production world situation
that does get to use IPCS, you don't get to do this.

There's the rub.

Regards,
Steve Thompson

-- opinions expressed by this poster may not reflect those opinions of
poster's employer --

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: LNKLST & APF Help

[Pommier, Rex R.]

George,

I believe that you may need to also do a LNKLST DELETE of the OEM#T
library before you do the LNKLST ADD statements.  I'm assuming the OEM#T
library is in the current LNKLST so it would be copied to the new one.
Just doing the LNKLST ADD statements will end up with 2 copies of OEM#T
in the LNKLST concatenation.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of George Rodriguez
Sent: Wednesday, January 06, 2010 12:37 PM
To: IBM-MAIN@bama.ua.edu
Subject: LNKLST & APF Help

This is a how to question. In the SYS1.PARMLIB(PROG00) member I have an
existing library that I really need to delete but I can't. Instead I
want to add a new entry in front of the one that's there now. As they
say a picture is worth a 1,000 word, so here's the net result of what I
want to do:

 

APF ADD DSNAME(OEM#P.CAI.EZT.R6M4.CAILIB)SMS  (this one
in front )

APF ADD DSNAME(OEM#T.CAI.CAILIB) SMS

 

And:

 

LNKLST ADD NAME(LNKLST00) DSN(OEM#P.CAI.EZT.R6M4.CAILIB)VOL(POEM01)
(this one in front)

LNKLST ADD NAME(LNKLST00) DSN(OEM#T.CAI.CAILIB) VOL(POEM00)

 

And I want to do it dynamically. For the APF it's just adding the entry
into PROG00 and issuing the SET PROG=XX command. I need to know if this
will work for the LNKLST?

 

LNKLST DEFINE NAME(LNKLST01) COPYFROM(CURRENT) 

LNKLST ADD NAME(LNKLST01) DSN(OEM#P.CAI.EZT.R6M4.CAILIB) VOL(POEM01)

LNKLST ADD NAME(LNKLST01) DSN(OEM#T.CAI.CAILIB)  VOL(POEM00)
<==<< this one to replace one that's there.

LNKLST ACTIVATE NAME(LNKLST01) 

 

The reason is that I need the R6M4 library to be read before the OEM#T
library.

 

Thanks in advance...

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCI and Auditors perceptions thereof

[Peter Vander Woude]

Don,

  It's not so much as blocking ftps and allowing normal ftp.  The normal ftp's 
go thru such that the firewall can do it's stateful checking and not cause a 
problem.  With FTPS, the datastream is encrypted by the time it hits the 
firewall, and does not conform to what the firewall thinks about "stateful", 
thus it drops the connection.  For our firewall, that means that if the command 
string coming across, does not end with an end of line character (I don't 
recall 
which one), it considers it a bad record, and terminates the session.

Peter

On Wed, 6 Jan 2010 08:04:36 -0800, Donald Russell 
 wrote:

>On Wed, Jan 6, 2010 at 06:15, Peter Vander Woude 
wrote:
>
>> Don,
>>
>>   If your firewall folks just recently upgraded the firewall, it could be
>> that the
>> upgrade "defaulted", or reset some configuration settings.  For FTPS, the
>> firewall cannot do what's referred to as "stateful checking".  I know ours
>> does
>> that, and if it does that on the control connection (and/or data
>> connection),
>> you will see the error you've been getting.
>>
>>
>That appears to be what happened I'll know for sure next week when the
>firewall people make the change to allow FTPS.
>
>For me, the red herring was that regular FTP works fine, which, to me, begs
>the question: What's the point of blocking FTPS without blocking FTP?
>
>Thanks for all the discussion and feedback...
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where have the control blocks gone? -- Now down in the dumps

[Don Poitras]

Thompson, Steve wrote:
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Don Poitras
> Sent: Wednesday, January 06, 2010 12:10 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Where have the control blocks gone?
> 
> 
> 
> Use FREE=CLOSE on the SYSMDUMP DD.
> 
> 
> That only works if you are not interested in any other ABEND or dump
> producing event that occurs.
> 
> If DISP=MOD would work for SYSMDUMP, I could figure out how to split the
> dumps by processing the file with REXX or some such.
> 
> [I have a special case with my stuff -- the things I work on are
> multi-threaded, multi-tasking and one failure may not be related at all
> to another.]
> 
> Let me give you an example:  Program "DRIVER" is running. In a daughter
> TCB a program is writing to DASD and gets an Sx37. Let's say that 10
> seconds later, under a different TCB the program I am interested in
> (SHUCKS) finally gets the S0C3 I set up. That's the dump I really want
> to look at.
> 
> But let's have even more fun. Before I can get to the dump DSN with
> IEBGENER (which would have to be invoked within this JOBSTEP to deal
> with the DISP=OLD...), another program under a different TCB ABENDS. I
> just lost the dump I'm really interested in. In this case, my only
> choice for this is a SLIP.
> 
> So the SYSMDUMP just can't handle this level of complexity.
> 
> Welcome to the world of a developer. Thankfully, I have the ability to
> issue MVS commands and can set SLIPs when and as I need them.
> 
> But for the typical programmer/analyst in a production world situation
> that does get to use IPCS, you don't get to do this.
> 
> There's the rub.

You can have multiple SYSMDUMPs. e.g.

//SYSMDUMP DD DISP=SHR,DSN=SASDTP.SYSMDUMP,FREE=CLOSE 
//SYSMDUMP DD DISP=SHR,DSN=SASDTP.SYSMDUM2,FREE=CLOSE 

and if you just can't stand not getting _every_ dump, code a SYSUDUMP 
as the last one (without FREE=CLOSE):

-- 
Don Poitras - zSeries R & D  -  SAS Institute Inc. -  SAS Campus Drive 
mailto:sas...@sas.com   (919)531-5637  Fax:677- Cary, NC 27513

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OSA Express3 questions

[R.S.]

Ed Finnell pisze:

Most of this should be covered in the SAPR  with the z10. Only one session  
from Denver SHARE has reference to OSA  Express. 2217 Software 
Considerations for z10 migration.


SAPR is the thing that were *never* been done here in Poland. BTDT many 
times. Even got (unofficially) SAPR manual for some of IBM devices.

Many things are different here...

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where have the control blocks gone? -- Now down in the dumps

[Wayne Driscoll]

Or you can use SYSMDUMP DD SYSOUT=class
And then use your handy dandy sysout management tool to save the dump to a 
disk dataset, and use IPCS.
See http://bama.ua.edu/cgi-bin/wa?A2=ind0709&L=ibm-main&P=R28921&I=1&X=-


===
Wayne Driscoll
OMEGAMON DB2 L3 Support/Development
wdrisco(AT)us.ibm.com
===



From:
Don Poitras 
To:
IBM-MAIN@bama.ua.edu
Date:
01/06/2010 01:10 PM
Subject:
Re: Where have the control blocks gone? -- Now down in the dumps
Sent by:
IBM Mainframe Discussion List 



Thompson, Steve wrote:
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Don Poitras
> Sent: Wednesday, January 06, 2010 12:10 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Where have the control blocks gone?
> 
> 
> 
> Use FREE=CLOSE on the SYSMDUMP DD.
> 
> 
> That only works if you are not interested in any other ABEND or dump
> producing event that occurs.
> 
> If DISP=MOD would work for SYSMDUMP, I could figure out how to split the
> dumps by processing the file with REXX or some such.
> 
> [I have a special case with my stuff -- the things I work on are
> multi-threaded, multi-tasking and one failure may not be related at all
> to another.]
> 
> Let me give you an example:  Program "DRIVER" is running. In a daughter
> TCB a program is writing to DASD and gets an Sx37. Let's say that 10
> seconds later, under a different TCB the program I am interested in
> (SHUCKS) finally gets the S0C3 I set up. That's the dump I really want
> to look at.
> 
> But let's have even more fun. Before I can get to the dump DSN with
> IEBGENER (which would have to be invoked within this JOBSTEP to deal
> with the DISP=OLD...), another program under a different TCB ABENDS. I
> just lost the dump I'm really interested in. In this case, my only
> choice for this is a SLIP.
> 
> So the SYSMDUMP just can't handle this level of complexity.
> 
> Welcome to the world of a developer. Thankfully, I have the ability to
> issue MVS commands and can set SLIPs when and as I need them.
> 
> But for the typical programmer/analyst in a production world situation
> that does get to use IPCS, you don't get to do this.
> 
> There's the rub.

You can have multiple SYSMDUMPs. e.g.

//SYSMDUMP DD DISP=SHR,DSN=SASDTP.SYSMDUMP,FREE=CLOSE 
//SYSMDUMP DD DISP=SHR,DSN=SASDTP.SYSMDUM2,FREE=CLOSE 

and if you just can't stand not getting _every_ dump, code a SYSUDUMP 
as the last one (without FREE=CLOSE):

-- 
Don Poitras - zSeries R & D  -  SAS Institute Inc. -  SAS Campus Drive 
mailto:sas...@sas.com   (919)531-5637  Fax:677- Cary, NC 27513

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Subject: Re: VTOC Fmt6

[David Staudacher]

Re: Split Cylinder DASD allocation 
 
I was curious to know if split-cylinder allocation still worked, and tried 
submitting a job using the OS/360 syntax: 
 
  //SPLITCYL DD  DSN=...,DISP=(,CATLG), 
  // UNIT=SYSDA,SPLIT=(6,CYL,10), 
  // DCB=(RECFM=FB,LRECL=80) 
 
To my surprise, I did NOT get a JCL error!  What I DID get was a 60 track file 
on a cylinder boundary, same as if I'd said "SPACE=(CYL,4)".  Obviously not an 
actual split-cylinder allocation, but interesting that "SPLIT=" is still 
acceptable 
syntax. 

 System IPLed at 02:51:20.597 on 11/08/2009  
 Release z/OS 01.09.00   
 Used LOADW1 in SYS1.IPLPARM on 4009 
 IEASYM LIST=SE  
 IEASYS LIST=00 (OP) 
 IODF device 4009
 IPL device 4903 volume PRDRA1 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Cobol rewrite variable length record

[Frank Swarbrick]

We have a program that has the following in it:

SELECT CVSCATF
   ASSIGN TO AS-CVSCATF
   ACCESS IS SEQUENTIAL   
   FILE STATUS IS FILE-STATUS.

 FD  CVSCATF   
 RECORD CONTAINS 17 TO 69 CHARACTERS.  
 01  CVSCATF-RECORD  PIC X(69).
 01  CVSCATF-RECORD-L7   PIC X(17).

 OPEN I-O CVSCATF
 READ CVSCATF INTO CVSC-AAT-RECORD
 ...change something here...
 REWRITE CVSCATF-RECORD FROM CVSC-AAT-RECORD

(Yes, we do check FILE-STATUS after each I-O.)

Some of the records are 17 characters and some are 69.  The file is a VSAM 
ESDS.  CVSC-AAT-RECORD is a group data item that is *not* varying in length.

This program works.

We then change CVSCATF is to a regular sequential file and change the SELECT to 
remove the AS- prefix

Now when we read a 17 byte record and try to REWRITE it we get an error with 
FILE STATUS 44, which means:
"A boundary violation exists because an attempt was made to rewrite a record to 
a file and the record was not the same size as the record being replaced, or an 
attempt was made to write or rewrite a record that was larger than the largest 
or smaller than the smallest record allowed by the RECORD IS VARYING clause of 
the associated file-name."

Obviously it's trying to rewrite it as 69 bytes in to a record that was 
previously only 17 bytes.

This can be fixed for the sequential file by adding RECORD IS VARYING DEPENDING 
ON CVSCATF-REC-LEN to the FD and creating CVSCATF-REC-LEN in working-storage.

My question is, why does it work when the file is VSAM, even without the RECORD 
IS VARYING?

Thanks,
Frank

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403


>>> 

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: LNKLST & APF Help

[Gibney, Dave]

  There's BEFORE and AFTER options on SETPROG LNKLST

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Pommier, Rex R.
> Sent: Wednesday, January 06, 2010 10:58 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: LNKLST & APF Help
> 
> George,
> 
> I believe that you may need to also do a LNKLST DELETE of the OEM#T
> library before you do the LNKLST ADD statements.  I'm assuming the
> OEM#T
> library is in the current LNKLST so it would be copied to the new one.
> Just doing the LNKLST ADD statements will end up with 2 copies of
OEM#T
> in the LNKLST concatenation.
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of George Rodriguez
> Sent: Wednesday, January 06, 2010 12:37 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: LNKLST & APF Help
> 
> This is a how to question. In the SYS1.PARMLIB(PROG00) member I have
an
> existing library that I really need to delete but I can't. Instead I
> want to add a new entry in front of the one that's there now. As they
> say a picture is worth a 1,000 word, so here's the net result of what
I
> want to do:
> 
> 
> 
> APF ADD DSNAME(OEM#P.CAI.EZT.R6M4.CAILIB)SMS  (this
one
> in front )
> 
> APF ADD DSNAME(OEM#T.CAI.CAILIB) SMS
> 
> 
> 
> And:
> 
> 
> 
> LNKLST ADD NAME(LNKLST00) DSN(OEM#P.CAI.EZT.R6M4.CAILIB)
VOL(POEM01)
> (this one in front)
> 
> LNKLST ADD NAME(LNKLST00) DSN(OEM#T.CAI.CAILIB)
VOL(POEM00)
> 
> 
> 
> And I want to do it dynamically. For the APF it's just adding the
entry
> into PROG00 and issuing the SET PROG=XX command. I need to know if
this
> will work for the LNKLST?
> 
> 
> 
> LNKLST DEFINE NAME(LNKLST01) COPYFROM(CURRENT)
> 
> LNKLST ADD NAME(LNKLST01) DSN(OEM#P.CAI.EZT.R6M4.CAILIB) VOL(POEM01)
> 
> LNKLST ADD NAME(LNKLST01) DSN(OEM#T.CAI.CAILIB)  VOL(POEM00)
> <==<< this one to replace one that's there.
> 
> LNKLST ACTIVATE NAME(LNKLST01)
> 
> 
> 
> The reason is that I need the R6M4 library to be read before the OEM#T
> library.
> 
> 
> 
> Thanks in advance...
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Cobol rewrite variable length record

[Steve Comstock]

Frank Swarbrick wrote:

We have a program that has the following in it:

SELECT CVSCATF
   ASSIGN TO AS-CVSCATF
   ACCESS IS SEQUENTIAL   
   FILE STATUS IS FILE-STATUS.


 FD  CVSCATF   
 RECORD CONTAINS 17 TO 69 CHARACTERS.  
 01  CVSCATF-RECORD  PIC X(69).

 01  CVSCATF-RECORD-L7   PIC X(17).

 OPEN I-O CVSCATF
 READ CVSCATF INTO CVSC-AAT-RECORD
 ...change something here...
 REWRITE CVSCATF-RECORD FROM CVSC-AAT-RECORD

(Yes, we do check FILE-STATUS after each I-O.)

Some of the records are 17 characters and some are 69.  The file is a VSAM 
ESDS.  CVSC-AAT-RECORD is a group data item that is *not* varying in length.

This program works.

We then change CVSCATF is to a regular sequential file and change the SELECT to 
remove the AS- prefix

Now when we read a 17 byte record and try to REWRITE it we get an error with 
FILE STATUS 44, which means:
"A boundary violation exists because an attempt was made to rewrite a record to a 
file and the record was not the same size as the record being replaced, or an attempt was 
made to write or rewrite a record that was larger than the largest or smaller than the 
smallest record allowed by the RECORD IS VARYING clause of the associated file-name."

Obviously it's trying to rewrite it as 69 bytes in to a record that was 
previously only 17 bytes.

This can be fixed for the sequential file by adding RECORD IS VARYING DEPENDING 
ON CVSCATF-REC-LEN to the FD and creating CVSCATF-REC-LEN in working-storage.

My question is, why does it work when the file is VSAM, even without the RECORD 
IS VARYING?

Thanks,
Frank



Question: are you running your tests under VSE or z/OS?

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

==> Ask about being added to our opt-in list:  <==
==>   * Early announcement of new courses  <==
==>   * Early announcement of new techincal papers <==
==>   * Early announcement of new promotions   <==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: LNKLST & APF Help

[George Rodriguez]

On z/OS v1.7?

Thanks,
George Rodriguez
Specialist II - IT Solutions
Application Support / Quality Assurance
PX - 47652
(561) 357-7652 (office)
(561) 707-3496 (mobile)
School District of Palm Beach County
3348 Forest Hill Blvd.
Room B-332
West Palm Beach, FL. 33406-5869
Florida's Only A-Rated Urban District For Five Consecutive Years

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Gibney, Dave
Sent: Wednesday, January 06, 2010 2:44 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: LNKLST & APF Help


  There's BEFORE and AFTER options on SETPROG LNKLST

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Pommier, Rex R.
> Sent: Wednesday, January 06, 2010 10:58 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: LNKLST & APF Help
> 
> George,
> 
> I believe that you may need to also do a LNKLST DELETE of the OEM#T
> library before you do the LNKLST ADD statements.  I'm assuming the
> OEM#T
> library is in the current LNKLST so it would be copied to the new one.
> Just doing the LNKLST ADD statements will end up with 2 copies of
OEM#T
> in the LNKLST concatenation.
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of George Rodriguez
> Sent: Wednesday, January 06, 2010 12:37 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: LNKLST & APF Help
> 
> This is a how to question. In the SYS1.PARMLIB(PROG00) member I have
an
> existing library that I really need to delete but I can't. Instead I
> want to add a new entry in front of the one that's there now. As they
> say a picture is worth a 1,000 word, so here's the net result of what
I
> want to do:
> 
> 
> 
> APF ADD DSNAME(OEM#P.CAI.EZT.R6M4.CAILIB)SMS  (this
one
> in front )
> 
> APF ADD DSNAME(OEM#T.CAI.CAILIB) SMS
> 
> 
> 
> And:
> 
> 
> 
> LNKLST ADD NAME(LNKLST00) DSN(OEM#P.CAI.EZT.R6M4.CAILIB)
VOL(POEM01)
> (this one in front)
> 
> LNKLST ADD NAME(LNKLST00) DSN(OEM#T.CAI.CAILIB)
VOL(POEM00)
> 
> 
> 
> And I want to do it dynamically. For the APF it's just adding the
entry
> into PROG00 and issuing the SET PROG=XX command. I need to know if
this
> will work for the LNKLST?
> 
> 
> 
> LNKLST DEFINE NAME(LNKLST01) COPYFROM(CURRENT)
> 
> LNKLST ADD NAME(LNKLST01) DSN(OEM#P.CAI.EZT.R6M4.CAILIB) VOL(POEM01)
> 
> LNKLST ADD NAME(LNKLST01) DSN(OEM#T.CAI.CAILIB)  VOL(POEM00)
> <==<< this one to replace one that's there.
> 
> LNKLST ACTIVATE NAME(LNKLST01)
> 
> 
> 
> The reason is that I need the R6M4 library to be read before the OEM#T
> library.
> 
> 
> 
> Thanks in advance...
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
--Palm Beach County Schools-

Rated "A" by the Florida Department of Education 2005-2009

-Home of Florida's first LEED Gold Certified School-
---http://www.palmbeachschools.org-

The District of Palm Beach County is an Equal Education Opportunity
Provider and Employer. Under Florida law, e-mail addresses are
public records. If you do not want your e-mail address released in
response to a public records request, do not send  electronic mail
to this entity. Instead, contact this office by phone or in
writing.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCI and Auditors perceptions thereof

[Donald Russell]

I guess it's a matter of interpreting their (security folks) intent. (Which
admittedly I don't know)...

Yes, I understand the technical part of your explanation... but the overall
effect is that FTPS is blocked while FTP is not if their intent is to
block file transfers, or selectively permit file transfers, then something
is misconfigured. Either the firewall should also deny FTP, or it should
allow FTPS. (Deny both or permit both, or I suppose it makes sense to deby
FTP but allow FTPS)

It seems odd to me that we may "FTP to anywhere[1]", but "FTPS is
effectively blocked". I need to fill out paper work to get FTPS working, yet
I don't have to do anything to use FTP. Yes, that's obviously an internal
issue.

[1] I haven't tested to see where the bounds of "anywhere" are... in my
case, all these transfers are internal.



On Wed, Jan 6, 2010 at 11:02, Peter Vander Woude wrote:

> Don,
>
>  It's not so much as blocking ftps and allowing normal ftp.  The normal
> ftp's
> go thru such that the firewall can do it's stateful checking and not cause
> a
> problem.  With FTPS, the datastream is encrypted by the time it hits the
> firewall, and does not conform to what the firewall thinks about
> "stateful",
> thus it drops the connection.  For our firewall, that means that if the
> command
> string coming across, does not end with an end of line character (I don't
> recall
> which one), it considers it a bad record, and terminates the session.
>
> Peter
>
> On Wed, 6 Jan 2010 08:04:36 -0800, Donald Russell
>  wrote:
>
> >On Wed, Jan 6, 2010 at 06:15, Peter Vander Woude
> wrote:
> >
> >> Don,
> >>
> >>   If your firewall folks just recently upgraded the firewall, it could
> be
> >> that the
> >> upgrade "defaulted", or reset some configuration settings.  For FTPS,
> the
> >> firewall cannot do what's referred to as "stateful checking".  I know
> ours
> >> does
> >> that, and if it does that on the control connection (and/or data
> >> connection),
> >> you will see the error you've been getting.
> >>
> >>
> >That appears to be what happened I'll know for sure next week when the
> >firewall people make the change to allow FTPS.
> >
> >For me, the red herring was that regular FTP works fine, which, to me,
> begs
> >the question: What's the point of blocking FTPS without blocking FTP?
> >
> >Thanks for all the discussion and feedback...
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> >Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Cobol rewrite variable length record

[Frank Swarbrick]

>>> On 1/6/2010 at 12:52 PM, in message <4b44ea14.4010...@trainersfriend.com>,
Steve Comstock  wrote:
>> My question is, why does it work when the file is VSAM, even without the 
> RECORD IS VARYING?
>> 
> 
> Question: are you running your tests under VSE or z/OS?

I tested sequential on both, but only tested VSAM on VSE.  I guess I just 
assumed that VSAM would behave the same on z/OS.

Frank

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Help with sysplex root filesystem.

[John McKown]

I just got it working. Turned out I mixed up two of the filesystems (mounted
on the other's mount point) and one of the filesystems upon which the mounts
failed did not have the necessary subdirectories created. Sheesh!

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone • (817)-961-6183 cell
john.mck...@healthmarkets.com • www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. HealthMarkets® is the brand name for products underwritten and
issued by the insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake
Life Insurance Company®, Mid-West National Life Insurance Company of
TennesseeSM and The MEGA Life and Health Insurance Company.SM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: LNKLST & APF Help

[Gibney, Dave]

Sorry, only AFTER... From z/OS 1.7 System Commands:
 

 
  |
|
  |   SETPROG
LNKLST,{DEFINE,NAME=lnklstname[,COPYFROM=lnklstname][,NOCHECK] }
| 
  |  {ADD,NAME=lnklstname,
| 
  | DSNAME=dsname[,VOLUME=volser][,ATBOTTOM]
| 
  |  [,ATTOP   ]
| 
  |  [,AFTER=dsname]
| 
  |[,CONCAT(CHECK | NOCHECK)]
} | 
  |  {DELETE,NAME=lnklstname,DSNAME=dsname
} | 
  |  {UNDEFINE,NAME=lnklstname
} | 
  |  {TEST,NAME=lnklstname,MODNAME=name
} | 
  |  {ACTIVATE,NAME=lnklstname
} | 
| |  {UPDATE,{JOB=jobname} [,DELAY=nn]
} | 
| |  {ASID=asid  } [DELAY=delay]
| 
  |  {UNALLOCATE
} | 
  |  {ALLOCATE
} | 
  |
|
 
|___
_|



Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of George Rodriguez
> Sent: Wednesday, January 06, 2010 11:50 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: LNKLST & APF Help
> 
> On z/OS v1.7?
> 
> Thanks,
> George Rodriguez
> Specialist II - IT Solutions
> Application Support / Quality Assurance
> PX - 47652
> (561) 357-7652 (office)
> (561) 707-3496 (mobile)
> School District of Palm Beach County
> 3348 Forest Hill Blvd.
> Room B-332
> West Palm Beach, FL. 33406-5869
> Florida's Only A-Rated Urban District For Five Consecutive Years
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Gibney, Dave
> Sent: Wednesday, January 06, 2010 2:44 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: LNKLST & APF Help
> 
> 
>   There's BEFORE and AFTER options on SETPROG LNKLST
> 
> Dave Gibney
> Information Technology Services
> Washington State University
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> > Behalf Of Pommier, Rex R.
> > Sent: Wednesday, January 06, 2010 10:58 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: LNKLST & APF Help
> >
> > George,
> >
> > I believe that you may need to also do a LNKLST DELETE of the OEM#T
> > library before you do the LNKLST ADD statements.  I'm assuming the
> > OEM#T
> > library is in the current LNKLST so it would be copied to the new
> one.
> > Just doing the LNKLST ADD statements will end up with 2 copies of
> OEM#T
> > in the LNKLST concatenation.
> >
> > Rex
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> > Behalf Of George Rodriguez
> > Sent: Wednesday, January 06, 2010 12:37 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: LNKLST & APF Help
> >
> > This is a how to question. In the SYS1.PARMLIB(PROG00) member I have
> an
> > existing library that I really need to delete but I can't. Instead I
> > want to add a new entry in front of the one that's there now. As
they
> > say a picture is worth a 1,000 word, so here's the net result of
what
> I
> > want to do:
> >
> >
> >
> > APF ADD DSNAME(OEM#P.CAI.EZT.R6M4.CAILIB)SMS  (this
> one
> > in front )
> >
> > APF ADD DSNAME(OEM#T.CAI.CAILIB) SMS
> >
> >
> >
> > And:
> >
> >
> >
> > LNKLST ADD NAME(LNKLST00) DSN(OEM#P.CAI.EZT.R6M4.CAILIB)
> VOL(POEM01)
> > (this one in front)
> >
> > LNKLST ADD NAME(LNKLST00) DSN(OEM#T.CAI.CAILIB)
> VOL(POEM00)
> >
> >
> >
> > And I want to do it dynamically. For the APF it's just adding the
> entry
> > into PROG00 and issuing the SET PROG=XX command. I need to know if
> this
> > will work for the LNKLST?
> >
> >
> >
> > LNKLST DEFINE NAME(LNKLST01) COPYFROM(CURRENT)
> >
> > LNKLST ADD NAME(LNKLST01) DSN(OEM#P.CAI.EZT.R6M4.CAILIB) VOL(POEM01)
> >
> > LNKLST ADD NAME(LNKLST01) DSN(OEM#T.CAI.CAILIB)  VOL(POEM00)
> > <==<< this one to replace one that's there.
> >
> > LNKLST ACTIVATE NAME(LNKLST01)
> >
> >
> >
> > The reason is that I need the R6M4 library to be read before the
> OEM#T
> > library.
> >
> >
> >
> > Thanks in advance...
> >
> >
> >
> >
-
> -
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
> INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> ---

Re: 360 programs on a z/10

[Howard Brazee]

On Tue, 05 Jan 2010 08:20:46 -0500, jmfbahciv  wrote:

>The goal of a war is to win to the point of changing
>the mindset of the enemy, especially the populace.

That's *a* goal of war.   

Goals in business or war are about of costs and benefits.   The quoted
goal (which doesn't define *how* the mind set is to be changed and how
we measure such success), doesn't look at costs. If what we value
in our country get destroyed, then the costs could be too high.It
is quite possible for both sides to lose.   

Certainly this principle is important in business.When we are
given a mandate to produce an IS result, we work with some assumptions
about costs which often need to be clarified and agreed upon.   We
also are wise in looking behind the mandate and know how it impacts
various goals of the company.


Aristotle said “The goal of war is peace, of business, leisure”.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Control-M and Schedule Groups question

[William Bishop]

A sister company of mine is attempting to use Control-M to support a new 
application.

They have defined 25000 jobs into 3000 schedule groups.

In operation, they have observered that it can take 6 minutes between the 
time a job ends and the next job takes off.

Has anyone running Control-M experienced this kind of issue?

Is anyone running Control-M with this many jobs and schedules groups?

We can take this off-list if desired.

Thanks

Bill Bishop

Specialist
Mainframe Support Group
Server Development & Support
Toyota Motor Engineering & Manufacturing North America, Inc.
bill.bis...@tema.toyota.com
(502) 570-6143

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCI and Auditors perceptions thereof

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Donald Russell
> Sent: Wednesday, January 06, 2010 12:03 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: PCI and Auditors perceptions thereof
> 

> 
> 
> The idea I was trying to convey is I wanted to invoke an sftp 
> file transfer
> from a program invoked as if it were a TSO command. I figured 
> everybody is
> familiar with "clist" as a concept, rather than a specific 
> language, and I
> specified REXX because I don't write clist language code any more.
> 
> Which is the correct noun to refer to a program, read from 
> SYSEXEC in a TSO
> address space? In TSO land I generally refer to them as 
> "clists" though
> they're written in REXX. In VM/CMS land I call them "EXECs" 
> even though they
> are written in REXX, or EXEC 2 or EXEC. On zLinux I call them 
> "scripts" or
> "shell scripts" even though they may be written in REXX, php, 
> bash shell,
> korn shell, etc...
> 

> 

I'm usually as exact as possible. That is, I tend to say "REXX program" or 
maybe even "ISPF EDIT REXX". For UNIX, I tend to say "BASH script", "Perl 
script", "awk script", ... . The only time when I normally leave that off is 
when the subject basically specifies the environment. I.e. "Does anybody have a 
Perl program to ..." will like get a response like "yes, I have a script to do 
that." If I want to switch languages, I'll reply like: "No, but I have such a 
script in REXX".

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: LNKLST & APF Help

[Mark Zelden]

Since the beginning of dynamic LNKLST  - OS/390 R3 (seems like a 
life time ago). 

BTW, after you "copy from current" you can delete the old one and
add the new one.  ASsuming there are no other duplicate modules
in the LNKLST, the order you specify those delete / add statements
don't matter nor will it affect performance if the ADDed library
goes to the end (which it will by default).

In addition to BEFORE and AFTER, there is also ATTOP.

Why not read the fine manual.  You can fine the init and tuning reference here:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/IEA2BK51

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html



On Wed, 6 Jan 2010 14:50:00 -0500, George Rodriguez
 wrote:

>On z/OS v1.7?
>
>Thanks,
>George Rodriguez
>Specialist II - IT Solutions
>Application Support / Quality Assurance
>PX - 47652
>(561) 357-7652 (office)
>(561) 707-3496 (mobile)
>School District of Palm Beach County
>3348 Forest Hill Blvd.
>Room B-332
>West Palm Beach, FL. 33406-5869
>Florida's Only A-Rated Urban District For Five Consecutive Years
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>Behalf Of Gibney, Dave
>Sent: Wednesday, January 06, 2010 2:44 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: LNKLST & APF Help
>
>
>  There's BEFORE and AFTER options on SETPROG LNKLST
>
>Dave Gibney
>Information Technology Services
>Washington State University
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>> Behalf Of Pommier, Rex R.
>> Sent: Wednesday, January 06, 2010 10:58 AM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: LNKLST & APF Help
>>
>> George,
>>
>> I believe that you may need to also do a LNKLST DELETE of the OEM#T
>> library before you do the LNKLST ADD statements.  I'm assuming the
>> OEM#T
>> library is in the current LNKLST so it would be copied to the new one.
>> Just doing the LNKLST ADD statements will end up with 2 copies of
>OEM#T
>> in the LNKLST concatenation.
>>
>> Rex
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>> Behalf Of George Rodriguez
>> Sent: Wednesday, January 06, 2010 12:37 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: LNKLST & APF Help
>>
>> This is a how to question. In the SYS1.PARMLIB(PROG00) member I have
>an
>> existing library that I really need to delete but I can't. Instead I
>> want to add a new entry in front of the one that's there now. As they
>> say a picture is worth a 1,000 word, so here's the net result of what
>I
>> want to do:
>>
>>
>>
>> APF ADD DSNAME(OEM#P.CAI.EZT.R6M4.CAILIB)SMS  (this
>one
>> in front )
>>
>> APF ADD DSNAME(OEM#T.CAI.CAILIB) SMS
>>
>>
>>
>> And:
>>
>>
>>
>> LNKLST ADD NAME(LNKLST00) DSN(OEM#P.CAI.EZT.R6M4.CAILIB)
>VOL(POEM01)
>> (this one in front)
>>
>> LNKLST ADD NAME(LNKLST00) DSN(OEM#T.CAI.CAILIB)
>VOL(POEM00)
>>
>>
>>
>> And I want to do it dynamically. For the APF it's just adding the
>entry
>> into PROG00 and issuing the SET PROG=XX command. I need to know if
>this
>> will work for the LNKLST?
>>
>>
>>
>> LNKLST DEFINE NAME(LNKLST01) COPYFROM(CURRENT)
>>
>> LNKLST ADD NAME(LNKLST01) DSN(OEM#P.CAI.EZT.R6M4.CAILIB) VOL(POEM01)
>>
>> LNKLST ADD NAME(LNKLST01) DSN(OEM#T.CAI.CAILIB)  VOL(POEM00)
>> <==<< this one to replace one that's there.
>>
>> LNKLST ACTIVATE NAME(LNKLST01)
>>
>>
>>
>> The reason is that I need the R6M4 library to be read before the OEM#T
>> library.
>>
>>
>>
>> Thanks in advance...
>>
>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html
>--
>--Palm Beach County Schools-
>
>Rated "A" by the Florida Department of Education 2005-2009
>
>-Home of Florida's first LEED Gold Certified School-
>---http://www.palmbeachschools.org-
>
>The District of Palm Beach County is an Equal Education Opportunity
>Provider and Employer. Under Florida law, e-mail addresses are
>public records. If you do not want your e-mail address released in
>response to a public records request, do not send  electronic mail
>to this entity. Instead, contact this office by phone

Re: Cobol rewrite variable length record

[Steve Comstock]

Frank Swarbrick wrote:

On 1/6/2010 at 12:52 PM, in message <4b44ea14.4010...@trainersfriend.com>,

Steve Comstock  wrote:
My question is, why does it work when the file is VSAM, even without the 

RECORD IS VARYING?
Question: are you running your tests under VSE or z/OS?


I tested sequential on both, but only tested VSAM on VSE.  I guess I just 
assumed that VSAM would behave the same on z/OS.

Frank



I would guess not. My notes from "VSAM for COBOL Programmers" say
ESDS supports update in place but no change in record length.

But I guess the only real proof is in the doing.

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

==> Ask about being added to our opt-in list:  <==
==>   * Early announcement of new courses  <==
==>   * Early announcement of new techincal papers <==
==>   * Early announcement of new promotions   <==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: LNKLST & APF Help

[Mark Zelden]

On Wed, 6 Jan 2010 14:46:07 -0600, Mark Zelden  wrote:

>Since the beginning of dynamic LNKLST  - OS/390 R3 (seems like a
>life time ago).
>
>BTW, after you "copy from current" you can delete the old one and
>add the new one.  ASsuming there are no other duplicate modules
>in the LNKLST, the order you specify those delete / add statements
>don't matter nor will it affect performance if the ADDed library
>goes to the end (which it will by default).
>
>In addition to BEFORE and AFTER, there is also ATTOP.
>
>Why not read the fine manual.  You can fine the init and tuning reference here:
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/IEA2BK51
>

And if you did, you would see I shouldn't have mentioned "BEFORE".  There
is no such animal.  (obviously you can accomplish the same thing with
AFTER and a different library name).

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: LNKLST & APF Help

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Mark Zelden
> Sent: Wednesday, January 06, 2010 12:49 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: LNKLST & APF Help
> 
> On Wed, 6 Jan 2010 14:46:07 -0600, Mark Zelden
>  wrote:
> 
> >Since the beginning of dynamic LNKLST  - OS/390 R3 (seems like a
> >life time ago).
> >
> >BTW, after you "copy from current" you can delete the old one and
> >add the new one.  ASsuming there are no other duplicate modules
> >in the LNKLST, the order you specify those delete / add statements
> >don't matter nor will it affect performance if the ADDed library
> >goes to the end (which it will by default).
> >
> >In addition to BEFORE and AFTER, there is also ATTOP.
> >
> >Why not read the fine manual.  You can fine the init and tuning
> reference here:
> >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/IEA2BK51
> >
> 
> And if you did, you would see I shouldn't have mentioned "BEFORE".
> There
> is no such animal.  (obviously you can accomplish the same thing with
> AFTER and a different library name).

Sorry about that, I spoke before I looked. I knew I could do it :)

> 
> Mark
> --
> Mark Zelden
> Sr. Software and Systems Architect - z/OS Team Lead
> Zurich North America / Farmers Insurance Group - ZFUS G-ITO
> mailto:mark.zel...@zurichna.com
> z/OS Systems Programming expert at
> http://expertanswercenter.techtarget.com/
> Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Cobol rewrite variable length record

[Farley, Peter x23353]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Frank Swarbrick
> Sent: Wednesday, January 06, 2010 2:44 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Cobol rewrite variable length record
> 
> We have a program that has the following in it:
> 
> SELECT CVSCATF
>ASSIGN TO AS-CVSCATF
>ACCESS IS SEQUENTIAL
>FILE STATUS IS FILE-STATUS.
> 
>  FD  CVSCATF
>  RECORD CONTAINS 17 TO 69 CHARACTERS.
>  01  CVSCATF-RECORD  PIC X(69).
>  01  CVSCATF-RECORD-L7   PIC X(17).
> 
>  OPEN I-O CVSCATF
>  READ CVSCATF INTO CVSC-AAT-RECORD
>  ...change something here...
>  REWRITE CVSCATF-RECORD FROM CVSC-AAT-RECORD
> 
> (Yes, we do check FILE-STATUS after each I-O.)
> 
> Some of the records are 17 characters and some are 69.  The file is a
VSAM
> ESDS.  CVSC-AAT-RECORD is a group data item that is *not* varying in
> length.

 
I don't quite understand why or how it works at all on VSE, but the
program needs to differentiate between the record lengths at the REWRITE
statement.  If asked to review that code in a peer-review process I
would have called out this coding as a problem.  RECORD IS VARYING is
not required if your records have some internal indicator or length
field that tells you which one they are.  Then the code could read
something like this:

 OPEN I-O CVSCATF
 READ CVSCATF INTO CVSC-AAT-RECORD
 ...change something here...
 IF RECORD-IS-LENGTH-69-TYPE 
REWRITE CVSCATF-RECORDFROM CVSC-AAT-RECORD
 ELSE
REWRITE CVSCATF-RECORD-17 FROM CVSC-AAT-RECORD
 END-IF

That should work anywhere for VSAM or SAM/QSAM, assuming of course that
your processing code doesn't change a length-69 into a length-17 or
vice-versa.

HTH

Peter


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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCI and Auditors perceptions thereof

[Hal Merritt]

Some of us exchange data with outside business partners (customers). The 
strategy has to be the same on both ends. Some partners are willing to 
negotiate, some insist on a specific solution.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Scott
Sent: Tuesday, January 05, 2010 6:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PCI and Auditors perceptions thereof

If the Co:Z product is not being used, then I personally think FTPS is a
better alternative to sftp on z/OS.  The big advantage is that you can
authenticate your account via Digital Certificates, instead of via
password.  Plus Digital Certificates are controlled by RACF (assuming it's
setup that way) and that gives you an easy "talk to the security nerds" when
auditors come around.

Scott

On Tue, Jan 5, 2010 at 4:32 PM, Kirk Wolf  wrote:

> I might be missing something, but I'm not aware of any additional
> costs related to adding OMVS segments to userids.   Its almost certain
> that *some* of your userids already have them, so that they can be
> "dubbed" to use Unix apis.
>
> Also, it is possible to setup an OMVS segment so that the default
> "shell" program restricts execution of anything other than what you
> want (like the sftp-server).   This could, for example, be used to
> restrict a user from using OMVS under TSO or logging in to SSH or
> TTY-Telnet with a Unix Shell.
>
> But, if FTP/TLS works with your firewall and or NAT routers and
> partner systems, then there's nothing wrong with it.
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
>
> On Tue, Jan 5, 2010 at 6:12 PM, Donald Russell 
> wrote:
> > On Tue, Jan 5, 2010 at 16:06, Kirk Wolf  wrote:
> >
> >> Don,
> >>
> >> RE: USS requirement for SFTP
> >>
> >> You can use IBM's sftp or our free Co:Z sftp if the z/OS userid has a
> >> valid OMVS segment. That's likely what is missing when you say
> >> that "USS is not enabled", since z/OS has required USS for TCP/IP
> >> support for a long time.
> >>
> >>
> > Thanks,
> > Yes... that helps with my understanding of what's what. :-) What I've
> > learned: It's not that OMVS isn't there, it's just we don't grant access
> to
> > it regularly except on one of our MVS systems. I wonder why that is
> I'm
> > guessing it's money. :-)
> >
> > Well, I have a few things to work with now, and next week I expect the
> > firewall thing to be resolved, so I may just stay with FTPS (TLS) since
> that
> > satisfies the security people.
> >
> > Cheers
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCI and Auditors perceptions thereof

[Shmuel Metz (Seymour J.)]

In , on
01/06/2010
   at 10:03 AM, Donald Russell  said:

>Which is the correct noun to refer to a program, read from SYSEXEC in a
>TSO address space?

Command[1] procedure, optionally preceded by an expletive. But see below.

>In VM/CMS land I call them "EXECs" even though they
>are written in REXX, or EXEC 2 or EXEC.

In CMS the file type for all three is EXEC.

>On zLinux I call them "scripts"

That's appropriate nomenclature in CMS and TSO as well. Not just for
command procedures, but also for, e.g., XEDIT macros.

>I have a TSO ID on each of these different MVS systems, no sharing of
>files between them,

Supporting my guess that they won't or can't share the Unix files in their
current configuration.

Do you have an NFS server accessible to all of your systems?

[1] Unless they're, e.g., ISPF macros.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PCI and Auditors perceptions thereof

[Shmuel Metz (Seymour J.)]

In , on 01/06/2010
   at 10:43 AM, Paul Gilmartin  said:

>Except that Rexx EXECs and CLISTs may be mingled in a single SYSPROC
>library.  Magic Numbers.

Well, magic comments. If it makes you feel better, in CMS there are three
script languages sharing a common file type, and the system has to read
the file to determine which interpreter to run. In *ix there's a generic
mechanism[1] for a script to specify the proper interpreter.

[1] Google for shebang
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Question on processing z/OS UNIX files using QSAM

[Steve Comstock]

In z/OS 1.11, a new option was provided for the DD statement
FILEDATA parameter: FILEDATA=RECORD; this implies data is
stored with each record having a 4 byte prefix that specifies
the length of the following data (different format than RDWs
for RECFM of VB).

When reading such a file using QSAM, the access method strips
off the prefix and passes just the data back to the program.
My question is: where is the record length? I can't see it
documented in the z/OS 1.11 pubs, and I don't have access to
1.11 to check macro definitions.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

==> Ask about being added to our opt-in list:  <==
==>   * Early announcement of new courses  <==
==>   * Early announcement of new techincal papers <==
==>   * Early announcement of new promotions   <==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Cobol rewrite variable length record

[Frank Swarbrick]

>>> On 1/6/2010 at 1:47 PM, in message <4b44f6c6.1010...@trainersfriend.com>, 
>>> Steve
Comstock  wrote:
> Frank Swarbrick wrote:
> On 1/6/2010 at 12:52 PM, in message <4b44ea14.4010...@trainersfriend.com>,
>> Steve Comstock  wrote:
 My question is, why does it work when the file is VSAM, even without the 
>>> RECORD IS VARYING?
>>> Question: are you running your tests under VSE or z/OS?
>> 
>> I tested sequential on both, but only tested VSAM on VSE.  I guess I just 
> assumed that VSAM would behave the same on z/OS.
>> 
>> Frank
>> 
> 
> I would guess not. My notes from "VSAM for COBOL Programmers" say
> ESDS supports update in place but no change in record length.
> 
> But I guess the only real proof is in the doing.

It's not changing the record length.  That is what is so odd.  It reads a 17 
byte VSAM record and then does the rewrite that seems to imply the 69 byte 
record, but it in fact rewrites just the 17.  Which is what is wanted, but I 
can't explain why it is working.

But I have spent enough time on this when I already have my solution that will 
work both for VSAM and regular SAM, on both z/OS and VSE.  I was just wondering 
why something that apparently shouldn't work was working.

Thanks!

Frank

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Cobol rewrite variable length record

[Farley, Peter x23353]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Frank Swarbrick
> Sent: Wednesday, January 06, 2010 5:24 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Cobol rewrite variable length record
> 
> >>> On 1/6/2010 at 1:47 PM, in message
> <4b44f6c6.1010...@trainersfriend.com>, Steve
> Comstock  wrote:
> > Frank Swarbrick wrote:
> > On 1/6/2010 at 12:52 PM, in message
> <4b44ea14.4010...@trainersfriend.com>,
> >> Steve Comstock  wrote:
>  My question is, why does it work when the file is VSAM, even
without
> the
> >>> RECORD IS VARYING?
> >>> Question: are you running your tests under VSE or z/OS?
> >>
> >> I tested sequential on both, but only tested VSAM on VSE.  I guess
I
> just
> > assumed that VSAM would behave the same on z/OS.
> >>
> >> Frank
> >>
> >
> > I would guess not. My notes from "VSAM for COBOL Programmers" say
> > ESDS supports update in place but no change in record length.
> >
> > But I guess the only real proof is in the doing.
> 
> It's not changing the record length.  That is what is so odd.  It
reads a
> 17 byte VSAM record and then does the rewrite that seems to imply the
69
> byte record, but it in fact rewrites just the 17.  Which is what is
> wanted, but I can't explain why it is working.
> 
> But I have spent enough time on this when I already have my solution
that
> will work both for VSAM and regular SAM, on both z/OS and VSE.  I was
just
> wondering why something that apparently shouldn't work was working.
> 
> Thanks!

COBOL (RE)WRITE is *supposed* use the length of the (fixed) 01-level
record name to control the length of the record that is written.  VSE
COBOL for the VSAM case *may* be saving the length from the read and
specifying it on the rewrite.  In any case, as I replied earlier, there
is no need to use RECORD IS VARYING, just use the internal record
indicators in your data to select which 01-level record name to use in
the rewrite.

HTH

Peter


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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Cobol rewrite variable length record

[Frank Swarbrick]

>>> On 1/6/2010 at 3:48 PM, in message
<053f2631ec9c584883847c8b4970a22805bcc...@josqems1.jsq.bsg.ad.adp.com>,
"Farley, Peter x23353"  wrote:
>>  -Original Message-
>> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>> Behalf Of Frank Swarbrick
>> Sent: Wednesday, January 06, 2010 5:24 PM
>> To: IBM-MAIN@bama.ua.edu 
>> Subject: Re: Cobol rewrite variable length record
>> 
>> >>> On 1/6/2010 at 1:47 PM, in message
>> <4b44f6c6.1010...@trainersfriend.com>, Steve
>> Comstock  wrote:
>> > Frank Swarbrick wrote:
>> > On 1/6/2010 at 12:52 PM, in message
>> <4b44ea14.4010...@trainersfriend.com>,
>> >> Steve Comstock  wrote:
>>  My question is, why does it work when the file is VSAM, even
> without
>> the
>> >>> RECORD IS VARYING?
>> >>> Question: are you running your tests under VSE or z/OS?
>> >>
>> >> I tested sequential on both, but only tested VSAM on VSE.  I guess
> I
>> just
>> > assumed that VSAM would behave the same on z/OS.
>> >>
>> >> Frank
>> >>
>> >
>> > I would guess not. My notes from "VSAM for COBOL Programmers" say
>> > ESDS supports update in place but no change in record length.
>> >
>> > But I guess the only real proof is in the doing.
>> 
>> It's not changing the record length.  That is what is so odd.  It
> reads a
>> 17 byte VSAM record and then does the rewrite that seems to imply the
> 69
>> byte record, but it in fact rewrites just the 17.  Which is what is
>> wanted, but I can't explain why it is working.
>> 
>> But I have spent enough time on this when I already have my solution
> that
>> will work both for VSAM and regular SAM, on both z/OS and VSE.  I was
> just
>> wondering why something that apparently shouldn't work was working.
>> 
>> Thanks!
> 
> COBOL (RE)WRITE is *supposed* use the length of the (fixed) 01-level
> record name to control the length of the record that is written.  VSE
> COBOL for the VSAM case *may* be saving the length from the read and
> specifying it on the rewrite.  In any case, as I replied earlier, there
> is no need to use RECORD IS VARYING, just use the internal record
> indicators in your data to select which 01-level record name to use in
> the rewrite.

Yeah, that is one way that I considered.  I like the RECORD IS VARYING because 
if someone writes a new record type to the file I don't have to make any 
changes to this program.  It will just rewrite with the same length it just 
read.

Thanks!

Frank

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Where have the control blocks gone? -- Now down in the dumps

[Don Imbriale]

If your "handy dandy sysout management tool" happens to be SDSF, be sure to
use line command XFC (or its command line equivalents) to maintain proper
formatting of the output data set.

-- 
--
Don Imbriale
  temporarily retired


On Wed, Jan 6, 2010 at 2:32 PM, Wayne Driscoll  wrote:

> Or you can use SYSMDUMP DD SYSOUT=class
> And then use your handy dandy sysout management tool to save the dump to a
> disk dataset, and use IPCS.
> See http://bama.ua.edu/cgi-bin/wa?A2=ind0709&L=ibm-main&P=R28921&I=1&X=-
>
>
> ===
> Wayne Driscoll
> OMEGAMON DB2 L3 Support/Development
> wdrisco(AT)us.ibm.com
> ===
>
>
>
> From:
> Don Poitras 
> To:
> IBM-MAIN@bama.ua.edu
> Date:
> 01/06/2010 01:10 PM
> Subject:
> Re: Where have the control blocks gone? -- Now down in the dumps
> Sent by:
> IBM Mainframe Discussion List 
>
>
>
> Thompson, Steve wrote:
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> > Behalf Of Don Poitras
> > Sent: Wednesday, January 06, 2010 12:10 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: Where have the control blocks gone?
> >
> > 
> >
> > Use FREE=CLOSE on the SYSMDUMP DD.
> > 
> >
> > That only works if you are not interested in any other ABEND or dump
> > producing event that occurs.
> >
> > If DISP=MOD would work for SYSMDUMP, I could figure out how to split the
> > dumps by processing the file with REXX or some such.
> >
> > [I have a special case with my stuff -- the things I work on are
> > multi-threaded, multi-tasking and one failure may not be related at all
> > to another.]
> >
> > Let me give you an example:  Program "DRIVER" is running. In a daughter
> > TCB a program is writing to DASD and gets an Sx37. Let's say that 10
> > seconds later, under a different TCB the program I am interested in
> > (SHUCKS) finally gets the S0C3 I set up. That's the dump I really want
> > to look at.
> >
> > But let's have even more fun. Before I can get to the dump DSN with
> > IEBGENER (which would have to be invoked within this JOBSTEP to deal
> > with the DISP=OLD...), another program under a different TCB ABENDS. I
> > just lost the dump I'm really interested in. In this case, my only
> > choice for this is a SLIP.
> >
> > So the SYSMDUMP just can't handle this level of complexity.
> >
> > Welcome to the world of a developer. Thankfully, I have the ability to
> > issue MVS commands and can set SLIPs when and as I need them.
> >
> > But for the typical programmer/analyst in a production world situation
> > that does get to use IPCS, you don't get to do this.
> >
> > There's the rub.
>
> You can have multiple SYSMDUMPs. e.g.
>
> //SYSMDUMP DD DISP=SHR,DSN=SASDTP.SYSMDUMP,FREE=CLOSE
> //SYSMDUMP DD DISP=SHR,DSN=SASDTP.SYSMDUM2,FREE=CLOSE
>
> and if you just can't stand not getting _every_ dump, code a SYSUDUMP
> as the last one (without FREE=CLOSE):
>
> --
> Don Poitras - zSeries R & D  -  SAS Institute Inc. -  SAS Campus Drive
> mailto:sas...@sas.com   (919)531-5637  Fax:677- Cary, NC 27513
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OSA Express3 questions

[Ted MacNEIL]

>SAPR is the thing that were *never* been done here in Poland. BTDT many 
times.
> Even got (unofficially) SAPR manual for some of IBM devices.
>Many things are different here...

The SAPR guides are publicly available.
I've used them in Canada, before the reps start the process.
I don't know all the legal ramifications of pulling them off and doing pre-work.
But, it does help prepare the site.
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 360 programs on a z/10

[Ted MacNEIL]

>Aristotle said “The goal of war is peace, of business, leisure”.

Making war for peace is like making love for virginity!
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: New cut of the CBT Tape - V478

[Paul Gillis]

Hi Sam,

Not a major issue, but I cannot access any of the cbttape.org links using
Safari, but it does work OK on I.E.8. This is accessing the updates page
etc.

Cheers, Paul

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: useless message at IPL

[Barbara Nitz]

Back in OS/390 R5 days I was presented a standalone dump where the exact 
same problem (a syntax error in bpxprm on a test system that nobody cared 
about but that *was* part of a productive parallel sysplex) had brought down 
a productive system due to the fact that the message prompting for the new 
member is a synchronous message (so XCF signalling won't work anymore).

At that time I investigated how that message asking for the new bpxprm was 
issued. It was NOT using ASA services back then! Oh, and you can blame the 
syntax checker for bpxprm members on me, too! On the grounds that each and 
every parmlib member that can stop an IPL should have a way to be checked 
before IPL. IBM allowed me to take a FIN apar for that.

The first time this occured here (years later) I asked everyone changing that 
parmlib member to use the syntax checker. The second time it occured, they 
got a bashing from me. But from those two occurances I know that the actual 
error message (which I believe is now using the ASA services) is issued 
hardcopy only, so no amount of HMC config will get you those messages 
(unless you have the HMC configured to receive the hardcopy message set - 
in which case Health checker will scream). All you'll see on the HMC is the 
prompting message. It usually takes either an sadump or backup members to 
come up and *see* what the error was. And since this is still NIP, you won't 
see those messages in operlog, either, until the prompt is replied to and 
NIP/MSI continued.

As for 'seeing' these hardcopy only messages: I believe that the design idea 
was that since all bpx statements are usually 'echoed' in hardcopy log, it is 
unnecessary to write out an extra message only stating the error. And who 
wants to see all bpx statements (and that they're correct) in the 'normal' 
cases? Unfortunately that means that no provision was made to just repeat 
the syntax error message which would enormously help. (Same is true for all 
those IPL-halting NIP messages like errors in lpalst or progxx - the system 
comes up somewhat, but chances are that you don't get to the point of 
actually seeing operlog/syslog.)

As for how to see these messages on the HMC: Those not in the hardcopy set 
can be made to appear if you make sure that no other NIP console can be 
found by NIP. The way to do that is either close the emulation that has the 
NIP console, or if that is impossible due to the location, configure the 
channel 
path to that (NIP/MCS) console offline from the HMC. That will get you the 
console of last resort - the HMC. As far as I am aware, you cannot see NIP 
messages on more than one console at a time.

I have no idea if having the HMC configured to receive the hardcopy set (via 
consolexx - which isn't read yet at this time) will actually get you these 
hardcopy-only NIP messages.

Best regards, Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Problems with CHECK(IBMIXGLOGR,IXGLOGR_STAGINGDSFULL)

[Barbara Nitz]

Quite late to answer this one, but here goes:

We had the exact same problem with a different LOGR health check. Problem it 
alerted to was solved, but the check still showed the exception. Big 
programming error, in my opinion.

Unless this has resolved itself by now: Try deleting the health check history, 
either or both by deleting and redefining the log stream (means to take down 
all health checker asids connected to it) and then coming up with empty (i.e. 
freshly defined) history datasets. If that doesn't work, just delete the check.

And whoever had the VERY COMPATIBLE idea to *require* a new, NOT 
downwards compatible format for this history dataset with z/OS 1.10?!?
So much for backwards compatibility! 

Regards, Barbara Nitz

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OSA Express3 questions

[R.S.]

Ted MacNEIL pisze:
SAPR is the thing that were *never* been done here in Poland. BTDT many 

times.

Even got (unofficially) SAPR manual for some of IBM devices.
Many things are different here...


The SAPR guides are publicly available.
Not exactly. They are available for customer (not secret), but not 
downloadable. I've read somewhere "to get SAPR manual ask your friendly 
IBMer" - and I did it.

However I don't know any URL when I can reach the SAPR manuals, do you?



I've used them in Canada, before the reps start the process.
I don't know all the legal ramifications of pulling them off and doing pre-work.

They even didn't agree what department is responsible for SAPR process.


But, it does help prepare the site.

But, the life without SAPR is definitely more exciting ;-)))

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.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.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html