Re: RES: 3174 Don't work with TCP/IP Under VMESA

[David Boyes]

> 5 of them. I have a 3174 with a T/R adapter. Runs 3 SNA printers.
> Talks SNA to an OSA-E card (for about a month now).  Has been running
> for a lng time
> (I have a 6th, a spare sitting in the corner)

Lots of people had Ethernet and T/R adapters in 3174s for SNA traffic,
but don't confuse these with the 3174 IP gateway feature. 

There was a RPQ feature for the 3174 that put a minimal IP stack into
the 3174 and mapped incoming tn3270 sessions to SNA LUs w/o a TCP stack
on the mainframe side. I think one of the US government agencies
required them (for some reason they didn't want to buy a Cisco CIP or
something normal), so IBM developed it as a PRPQ for certain regions of
the world.

They were incredibly rare (I've only seen two in 30 years), insanely
expensive (about the same price as the 3174 shell itself), and you could
have only 1 per physical 3174 box because of the processor resource
requirements of the IP stack, which made them really a bad choice for
price/performance/floor space.

I got mine from someone who was having the same problem Carlos is facing
-- when VTAM goes away, the IP gateway feature becomes a very expensive
boat anchor. Cost me the price of hauling the 3174 away (which was a
good trick in a Geo Metro). Goes along with the AEA and the other
strange adapters in my collection of random junk.

Come to think of it, 3174s filled with concrete do make very nice boat
anchorages. One of the local small towns used about 30 of them to create
a retaining wall for the local boat ramp. 8-)

-- db

Re: RES: 3174 Don't work with TCP/IP Under VMESA

[Alan Altmark]

On Wednesday, 07/11/2007 at 05:36 EDT, Carlos Bodra <[EMAIL PROTECTED]> 
wrote:

> 3174 can participate in a TCP/IP network if has Ethernet adapter or into 
a
> Token Ring if configured with TKR adapter. There are some specific
> configuration questions to make this possible.

As an SNA PU, yes.  As a LAN CHANNEL STATION (LCS)-type device, no.

For a pre-OSA system, you need a 3172 or equivalent.

Alan Altmark
z/VM Development
IBM Endicott

Re: RES: 3174 Don't work with TCP/IP Under VMESA

[Ron Schmiedge]

5 of them. I have a 3174 with a T/R adapter. Runs 3 SNA printers.
Talks SNA to an OSA-E card (for about a month now).  Has been running
for a lng time
(I have a 6th, a spare sitting in the corner)

On 7/11/07, Carlos Bodra <[EMAIL PROTECTED]> wrote:

So David, there are 4 of them in world. I have 3 of them here, one gateway
and 2 DSPU units.


-Mensagem original-
De: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Em nome
de David Boyes
Enviada em: quarta-feira, 11 de julho de 2007 19:16
Para: IBMVM@LISTSERV.UARK.EDU
Assunto: Re: RES: 3174 Don't work with TCP/IP Under VMESA

That 3174 IP gateway feature only operates when the 3174 is a) running SNA
microcode and is b) attached to VTAM. It is not supported for use with the
VM TCP stack.and does not work.

It's nie to know that you have the other one of those beasts. I thought I
had the only one left in the world...

-Original Message-
From: "Carlos Bodra" <[EMAIL PROTECTED]>
To: "IBMVM@LISTSERV.UARK.EDU" 
Sent: 7/11/07 5:37 PM
Subject: RES: 3174 Don't work with TCP/IP Under VMESA

Alan,

3174 can participate in a TCP/IP network if has Ethernet adapter or into a
Token Ring if configured with TKR adapter. There are some specific
configuration questions to make this possible.

Carlos

unsubscribe

[Scott Ewing]

_
PC Magazine’s 2007 editors’ choice for best web mail—award-winning Windows Live 
Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HMWL_mini_pcmag_0707

Re: Trouble with COPYFILE to shorten Record

[Rob van der Heij]

On 7/11/07, Mike Walter <[EMAIL PROTECTED]> wrote:


- PIPE < fn ft fm | BROWSE- but no hex viewing unless you add stage(s) 
for that


The 'browse' stage does keep the viewed portion of the data in memory
to allow you to page back again. Not really a concern with 5000
records of 13 bytes though.

But as I read his note, the discussion about XEDIT was not to view the
records but because he wanted to use that to shorten the records.
While using XEDIT for that is not safe with non-text data (since it
will play games with trailing blanks) I fail to see why one could not
edit a file of 700 KB in even a 10 MB virtual machine.

Rob

RES: RES: 3174 Don't work with TCP/IP Under VMESA

[Carlos Bodra]

So David, there are 4 of them in world. I have 3 of them here, one gateway
and 2 DSPU units.


-Mensagem original-
De: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Em nome
de David Boyes
Enviada em: quarta-feira, 11 de julho de 2007 19:16
Para: IBMVM@LISTSERV.UARK.EDU
Assunto: Re: RES: 3174 Don't work with TCP/IP Under VMESA

That 3174 IP gateway feature only operates when the 3174 is a) running SNA
microcode and is b) attached to VTAM. It is not supported for use with the
VM TCP stack.and does not work.

It's nie to know that you have the other one of those beasts. I thought I
had the only one left in the world...

-Original Message-
From: "Carlos Bodra" <[EMAIL PROTECTED]>
To: "IBMVM@LISTSERV.UARK.EDU" 
Sent: 7/11/07 5:37 PM
Subject: RES: 3174 Don't work with TCP/IP Under VMESA

Alan,

3174 can participate in a TCP/IP network if has Ethernet adapter or into a
Token Ring if configured with TKR adapter. There are some specific
configuration questions to make this possible.

Carlos 

-Mensagem original-
De: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Em nome
de Alan Altmark
Enviada em: quarta-feira, 11 de julho de 2007 18:26
Para: IBMVM@LISTSERV.UARK.EDU
Assunto: Re: 3174 Don't work with TCP/IP Under VMESA

On Wednesday, 07/11/2007 at 04:45 EDT, Sergio Lima 
<[EMAIL PROTECTED]> wrote:

> We have a problem here, may be why we don't know very well the 3174 
machine.
> We are running TCP/IP under VM/ESA, but the 3174 machine don't want 
work.
> Unfortunatelly We don't have here in our hands, the TCPMAINT Log, but 
tomorrow, 
> may be.
> For now, We have our IOCP configuration, and our TCPIP Profile, and We 
want 
> know, if is possible someone help us.
> We will use TCP/IP, only for Telnet services, no FTP, no SMTP, etc...
> Here, the IOCP Configuration :

TCP/IP can't use a 3174.  3174 is a terminal control unit.  You need a 
3172.

Alan Altmark
z/VM Development
IBM Endicott

Re: PIPEDDR & TERSE and other stuff

[Rob van der Heij]

On 7/11/07, Graeme Moss <[EMAIL PROTECTED]> wrote:


Just an aside, I thought I would update the code so it used
standard PIPES but when I did that TCPIP packets were lost.
Maybe TCPCLIENT and TCPLISTEN have different code or maybe I
screwed it up or maybe it was timing.


If you mean using the version of CMS Pipelines that comes with z/VM, I
fear you would at least  miss the trackread and trackwrite stage.
Those are the ones that Bruce is using too. Those stages are very
useful to handle non-CMS disks.

The difference for the TCP/IP stages is only for some specific cases
at termination of the connection.

Rob

Re: RES: 3174 Don't work with TCP/IP Under VMESA

[David Boyes]

That 3174 IP gateway feature only operates when the 3174 is a) running SNA 
microcode and is b) attached to VTAM. It is not supported for use with the VM 
TCP stack.and does not work.

It's nie to know that you have the other one of those beasts. I thought I had 
the only one left in the world...

-Original Message-
From: "Carlos Bodra" <[EMAIL PROTECTED]>
To: "IBMVM@LISTSERV.UARK.EDU" 
Sent: 7/11/07 5:37 PM
Subject: RES: 3174 Don't work with TCP/IP Under VMESA

Alan,

3174 can participate in a TCP/IP network if has Ethernet adapter or into a
Token Ring if configured with TKR adapter. There are some specific
configuration questions to make this possible.

Carlos 

-Mensagem original-
De: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Em nome
de Alan Altmark
Enviada em: quarta-feira, 11 de julho de 2007 18:26
Para: IBMVM@LISTSERV.UARK.EDU
Assunto: Re: 3174 Don't work with TCP/IP Under VMESA

On Wednesday, 07/11/2007 at 04:45 EDT, Sergio Lima 
<[EMAIL PROTECTED]> wrote:

> We have a problem here, may be why we don't know very well the 3174 
machine.
> We are running TCP/IP under VM/ESA, but the 3174 machine don't want 
work.
> Unfortunatelly We don't have here in our hands, the TCPMAINT Log, but 
tomorrow, 
> may be.
> For now, We have our IOCP configuration, and our TCPIP Profile, and We 
want 
> know, if is possible someone help us.
> We will use TCP/IP, only for Telnet services, no FTP, no SMTP, etc...
> Here, the IOCP Configuration :

TCP/IP can't use a 3174.  3174 is a terminal control unit.  You need a 
3172.

Alan Altmark
z/VM Development
IBM Endicott

PIPEDDR & TERSE and other stuff

[Graeme Moss]

Greetings Listers,

PIPEDDR can use TERSE or PACK stages for compression or use 
no compression.. It only fails if TERSE option is specified 
and the stage is not available. It is written so it does not 
rely on TERSE

I have used PIPEDDR with PACK option to transfer complete 
3390s from one data centre to another and it works well. It 
saved the delay of waiting for a courier to take a 
cartridge.

Just an aside, I thought I would update the code so it used 
standard PIPES but when I did that TCPIP packets were lost. 
Maybe TCPCLIENT and TCPLISTEN have different code or maybe I 
screwed it up or maybe it was timing.

Another aside. Thanks to the author Bruce Hayden publishing 
the code I was able to use PIPEDDR as a model and instead of 
using TRACKREAD and TRACKWRITE to read and write dasd I used 
READER and URO to read and write spool making a very simple 
NJETCP link.

Cheers Graeme 

Re: PIPEDDR

[Schuh, Richard]

Since the Support Center now accepts VMARC packed files, is there really
any reason to demand TERSE? Will TERSE results be smaller? I doubt it.
The reason for my doubt is that I have VMARC packed a large (1.5G) TPF
dump and found that it was exactly the same size as it was when
processed by a proprietary routine created by a person whose doctoral
dissertation was about data compaction. 

I suspect that everyone on this list has VMARC. If not, it is easily
obtainable, and the price is right. 

Of course, you may have other reasons for wanting TERSE. If so, you can
ignore the above and continue complaining or wishing, whichever fits. 

Regards, 
Richard Schuh 


-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, July 11, 2007 2:29 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: PIPEDDR

For some reason, IBM doesn't want to make TERSE available to VM 
customers.  You used to be able to order a package on IBMLINK called
QSEN=
D 
that was supposed to be used to pack VM dumps before sending them to the
=

support center, (back in the days when that was a frequent event :-)> ).
=
 
QSEND is basically TERSE shipped as QSEND MODULE instead of TERSE
MODULE.=
  
I say it is/was basically the same as TERSE, except that the DETERSE 
MODULE for VM could not DETERSE a file created with QSEND, (IBM wanted
it=
 
to be a one way thing).  I found out that the output created by QSEND
was=
 
different from TERSE by only one byte!  (The first byte.)  I figured out
=

how to ZAP DETERSE so that it would work with QSEND files as well as 
TERSEd files.  I don't know if you can still order QSEND for VM on
IBMLIN=
K 
or not, (it is not a PTF, you had to order it as a package called
QSEND).=


Dale R. Smith
Persona Non Grata

Re: PIPEDDR

[Glenn Knickerbocker]

Rob van der Heij wrote:
> The Piper normally has a good reason not to put something in the
> runtime library, but I don't know the motivation in this particular
> case. You could ask on CMSPIP-L if you have strong desires.

Might just be that he hasn't felt the urge to wrangle with IBM Legal
since the LZW patents expired.

¬R

RES: 3174 Don't work with TCP/IP Under VMESA

[Carlos Bodra]

Alan,

3174 can participate in a TCP/IP network if has Ethernet adapter or into a
Token Ring if configured with TKR adapter. There are some specific
configuration questions to make this possible.

Carlos 

-Mensagem original-
De: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Em nome
de Alan Altmark
Enviada em: quarta-feira, 11 de julho de 2007 18:26
Para: IBMVM@LISTSERV.UARK.EDU
Assunto: Re: 3174 Don't work with TCP/IP Under VMESA

On Wednesday, 07/11/2007 at 04:45 EDT, Sergio Lima 
<[EMAIL PROTECTED]> wrote:

> We have a problem here, may be why we don't know very well the 3174 
machine.
> We are running TCP/IP under VM/ESA, but the 3174 machine don't want 
work.
> Unfortunatelly We don't have here in our hands, the TCPMAINT Log, but 
tomorrow, 
> may be.
> For now, We have our IOCP configuration, and our TCPIP Profile, and We 
want 
> know, if is possible someone help us.
> We will use TCP/IP, only for Telnet services, no FTP, no SMTP, etc...
> Here, the IOCP Configuration :

TCP/IP can't use a 3174.  3174 is a terminal control unit.  You need a 
3172.

Alan Altmark
z/VM Development
IBM Endicott

Re: vswitch problem

[Shimon Lebowitz]

> You need to provide output from QUERY VSWITCH and QUERY NIC DETAILS while
> the VM stack is up.

Did the output I provided give you (or anyone else) 
any ideas on this? My vswitch is now frozen, waiting
for advice...

Thanks,
Shimon

Re: PIPEDDR

[[EMAIL PROTECTED]]

For some reason, IBM doesn't want to make TERSE available to VM 
customers.  You used to be able to order a package on IBMLINK called QSEN
D 
that was supposed to be used to pack VM dumps before sending them to the 

support center, (back in the days when that was a frequent event :-)> ). 
 
QSEND is basically TERSE shipped as QSEND MODULE instead of TERSE MODULE.
  
I say it is/was basically the same as TERSE, except that the DETERSE 
MODULE for VM could not DETERSE a file created with QSEND, (IBM wanted it
 
to be a one way thing).  I found out that the output created by QSEND was
 
different from TERSE by only one byte!  (The first byte.)  I figured out 

how to ZAP DETERSE so that it would work with QSEND files as well as 
TERSEd files.  I don't know if you can still order QSEND for VM on IBMLIN
K 
or not, (it is not a PTF, you had to order it as a package called QSEND).


Dale R. Smith
Persona Non Grata

Re: 3174 Don't work with TCP/IP Under VMESA

[Alan Altmark]

On Wednesday, 07/11/2007 at 04:45 EDT, Sergio Lima 
<[EMAIL PROTECTED]> wrote:

> We have a problem here, may be why we don't know very well the 3174 
machine.
> We are running TCP/IP under VM/ESA, but the 3174 machine don't want 
work.
> Unfortunatelly We don't have here in our hands, the TCPMAINT Log, but 
tomorrow, 
> may be.
> For now, We have our IOCP configuration, and our TCPIP Profile, and We 
want 
> know, if is possible someone help us.
> We will use TCP/IP, only for Telnet services, no FTP, no SMTP, etc...
> Here, the IOCP Configuration :

TCP/IP can't use a 3174.  3174 is a terminal control unit.  You need a 
3172.

Alan Altmark
z/VM Development
IBM Endicott

Re: Trouble with COPYFILE to shorten Record

[[EMAIL PROTECTED]]

Since you only seem to be interested in the first 13 bytes of each record
, 
you could also try using the XEDIT Width option, i.e. XEDIT TXJIM FILELIS
T 
A (W 13  This will Xedit only the first 13 bytes of each record and will 

require a lot less virtual storage.  By default, Xedit trys to allocate a
 
buffer that is big enough to hold the longest record as well as all of th
e 
records in the file, (4920 * 169).  I have used this technique for files 

that have a few very large records that causes Xedit to attempt to 
allocate an extremely large buffer, when I am only interested in the firs
t 
72 bytes of each record, for example.

Dale R. Smith
Persona Non Grata

On Wed, 11 Jul 2007 15:08:19 -0400, Stracka, James (GTI) 
<[EMAIL PROTECTED]> wrote:

>I am trying to copy a file with the LRECL option to shorten it.
>
>e.g.
>
>Filename Filetype Fm Format LreclRecords
>TXJIMFILELIST A0 V169   4920
>
>COPYFILE TXJIM FILELIST A SORTER FILELIST A (LRECL 13
>
>I expected the result to be a file with LRECL 13 but it is:
>
>Filename Filetype Fm Format Lrecl
>SORTER   FILELIST A0 V169
>
>I need to do this soon.  The file is too big to use XEDIT in a 2G
>machine.
>
>Anybody have a PIPE to do this.
>
>Note:  The real file is hexadecimal data, not text.
>
>Jim
>

Re: Trouble with COPYFILE to shorten Record

[Mike Walter]

If you are just trying to view it and it won't fit in XEDIT try one or 
more of:

- BROWSE fn ft fm  - BROWSE has HEX ON|OFF|CHAR

- SHOW fn ft fm - SHOW has HEXMODE and HEXTYPE commands, 
 and I can offer a HEXVIEW XEDIT file 
(based on Will Roden's work) will display hex data vertically like ISPF

- PIPE < fn ft fm | BROWSE- but no hex viewing unless you add 
stage(s) for that

or, if your paging system can handle it...

- CP DEFINE STOR 16E, then IPL CMS and XEDIT the file - of course you'd 
need to change the directory entry to set their machine size that high.
  And... you won't get an actual 16E of storage even in current z9's.  The 
actual storage will be reduced to the maximum your hardware can support.
  But cool to try, anyway.

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily 
represent the opinions or policies of Hewitt Associates.




"Stracka, James (GTI)" <[EMAIL PROTECTED]> 

Sent by: "The IBM z/VM Operating System" 
07/11/2007 02:08 PM
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Trouble with COPYFILE to shorten Record






I am trying to copy a file with the LRECL option to shorten it. 
e.g. 
Filename Filetype Fm Format LreclRecords 
TXJIMFILELIST A0 V169   4920 
COPYFILE TXJIM FILELIST A SORTER FILELIST A (LRECL 13 
I expected the result to be a file with LRECL 13 but it is: 
Filename Filetype Fm Format Lrecl 
SORTER   FILELIST A0 V169 
I need to do this soon.  The file is too big to use XEDIT in a 2G machine. 

Anybody have a PIPE to do this. 
Note:  The real file is hexadecimal data, not text. 
Jim 

This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically 
indicated, this message is not an offer to sell or a solicitation of any 
investment products or other financial product or service, an official 
confirmation of any transaction, or an official statement of Merrill 
Lynch. Subject to applicable law, Merrill Lynch may monitor, review and 
retain e-communications (EC) traveling through its networks/systems. The 
laws of the country of each sender/recipient may impact the handling of 
EC, and EC may be archived, supervised and produced in countries other 
than the country in which you are located. This message cannot be 
guaranteed to be secure or error-free. This message is subject to terms 
available at the following link: http://www.ml.com/e-communications_terms/
. By messaging with Merrill Lynch you consent to the foregoing.


 
The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient 
is strictly prohibited.

3174 Don't work with TCP/IP Under VMESA

[Sergio Lima]

Hi list,
   
  We have a problem here, may be why we don't know very well the 3174 machine.
  We are running TCP/IP under VM/ESA, but the 3174 machine don't want work.
  Unfortunatelly We don't have here in our hands, the TCPMAINT Log, but 
tomorrow, may be.
  For now, We have our IOCP configuration, and our TCPIP Profile, and We want 
know, if is possible someone help us.
  We will use TCP/IP, only for Telnet services, no FTP, no SMTP, etc...
  Here, the IOCP Configuration :
   
  MSG  IDMSG1='RAMAC - VM/ESA 2.2.0',SYSTEM=(9121,1)
CH0   CHPIDPATH=((00)),TYPE=BL
CH1   CHPIDPATH=((01)),TYPE=BL
CH2   CHPIDPATH=((02)),TYPE=BL
CH3   CHPIDPATH=((03)),TYPE=BL
CH4   CHPIDPATH=((04)),TYPE=BL
CH5   CHPIDPATH=((05)),TYPE=BL
CH01  CHPIDPATH=((06)),TYPE=BL
CH02  CHPIDPATH=((07)),TYPE=BL
CH03  CHPIDPATH=((08)),TYPE=BL
CH05  CHPIDPATH=((09)),TYPE=BL
CH06  CHPIDPATH=((0A)),TYPE=BL
*
* UNIDADE 3203 - IMPRESSORA
*
CU000CNTLUNIT CUNUMBR=00,PATH=(00),SHARED=N,PROTOCL=D, +
   UNIT=2821,UNITADD=((2E,1))
*
 IODEVICE ADDRESS=02E,CUNUMBR=(00),UNIT=3203,MODEL=5
*
* UNIDADE 3174 - INTERNA CPU - PROTOCOLO SNA
*
CU003 CNTLUNIT CUNUMBR=003,PATH=(01),SHARED=YB,UNIT=3791L, X
   UNITADD=((20,4))
*
DV003 IODEVICE CUNUMBR=003,UNIT=3791L,ADDRESS=(620,4)
*
* UNIDADE 3174 - INTERNA CPU - PROTOCOLO SNA
*
CU00X CNTLUNIT CUNUMBR=011,PATH=(0A),SHARED=YB,UNIT=3791L, X
   UNITADD=((20,4))
*
DV00X IODEVICE CUNUMBR=011,UNIT=3791L,ADDRESS=(A20,4)
*
* UNIDADES DE CARTUCHO 3480 - IDRC
*
CU004 CNTLUNIT CUNUMBR=004,PATH=(02),PROTOCL=S,SHARED=N,UNIT=3480, X
   UNITADD=((70,16))
DV004 IODEVICE CUNUMBR=004,UNIT=3480,ADDRESS=(270,16)
***
* TERMINAIS 3274-31D + 3278 + 3287*
***
*
CU005CNTLUNIT CUNUMBR=05,UNIT=3274,UNITADD=((A0,032)),PATH=(03),   +
   PROTOCL=D,SHARED=YB
*
 IODEVICE CUNUMBR=05,UNIT=3278,ADDRESS=(03A0,032),TIMEOUT=Y,   X
   MODEL=2
*
CU006CNTLUNIT CUNUMBR=06,UNIT=3274,UNITADD=((A0,032)),PATH=(04),   +
   PROTOCL=D,SHARED=YB
*
 IODEVICE CUNUMBR=06,UNIT=3278,ADDRESS=(04A0,032),TIMEOUT=Y,   X
   MODEL=2
*
CU007CNTLUNIT CUNUMBR=07,UNIT=3274,UNITADD=((A0,032)),PATH=(05),   +
   PROTOCL=D,SHARED=YB
*
 IODEVICE CUNUMBR=07,UNIT=3278,ADDRESS=(05A0,032),TIMEOUT=Y,   X
   MODEL=2
*
* DISCOS RAMAC II - B23 - EMULANDO 3390
*
CU010 CNTLUNIT CUNUMBR=010,PATH=(06,07,08,09),PROTOCL=S4,SHARED=N, X
   UNIT=3990,UNITADD=((60,64))
DV011 IODEVICE CUNUMBR=010,UNIT=3380,ADDRESS=(660,64),TIMEOUT=Y

   
  And here, the PROFILE TCPIP for VM MACHINE :
   
  ; 
;
;I N S T A L L A T I O N I N S T R U C T I O N S
;
; The Installation EXEC has invoked XEDIT to allow you to update
; the passwords for the TCP/IP Protocol Service Machines, e.g.,
; FTPSERVE. The passwords are further down in this file and are
; coded as part of the AUTOLOG statement. If you will LOCATE the
; fourth occurrence of the string 'AUTOLOG' (minus the 's), you
; can then provide the correct password for each of the Protocol
; Service machines. This is necessary for the verification EXEC,
; V5735FAL, to execute successfully, as well as to allow TCPIP to
; automatically bring up the Protocol Service Machines WHENEVER
; the TCPIP virtual machine is initialized.
;
;
; 
  ; Use statements below to alter sizes of free pools.
; See section in this manual on TCP/IP Configuration
; Commands for more information.
  ACBPOOLSIZE 1000
ADDRESSTRANSLATIONPOOLSIZE  1500
CCBPOOLSIZE 150
DATABUFFERPOOLSIZE  160
ENVELOPEPOOLSIZE750
IPROUTEPOOLSIZE 300
LARGEENVELOPEPOOLSIZE   50
RCBPOOLSIZE 50
SCBPOOLSIZE 256
SKCBPOOLSIZE256
SMALLDATABUFFERPOOLSIZE 0
TCBPOOLSIZE 256
UCBPOOLSIZE 100
  ; Turn off all TCP/IP tracing
NOTRACE
  ; Flush the arp tables every 5 minutes
ARPAGE 5
  ; The SYSCONTACT and SYSLOCATION statements are used for SNMP.
;
; SYSCONTACT is the contact person for this managed node and how to
; contact this person.  Used for VM agent MIB variable sysContact
SYSCONTACT
   MAIN OPERATOR (RAMAL 1273 - ANCHIETA)
ENDSYSCONTACT
  ; SYSLOCATION is the physical location of this node.  Used for VM
; agent MIB variable sysLocation
SYSLOCATION
   ANCHIETA
ENDSYSLOCATION
  
; Inform the following users of serious errors
INFORM
OPERATOR TCPMAINT 
  ENDINFORM
  ; Obey the following users for restricted commands
OBEY
OPERATOR TCPMAINT SNMPD SNMPQE ROUTED REXECD 
  ENDOBEY
  ; Autolog the 

Re: Performance Toolkit: DCSS size too small

[Kris Buelens]

So, open a problem with the IBM support center.

Kris

2007/7/11, RPN01 <[EMAIL PROTECTED]>:


 Update: Increasing the virtual memory size of the PERFSVM userid solved
the problem. I wish PerfKit gave more useful messages I've been chasing
the wrong problem all day.

--
   .~.Robert P. Nix Mayo Foundation
   /V\RO-OE-5-55  200 First Street SW
 / ( ) \  507-284-0844   Rochester, MN 55905
^^-^^   -
"In theory, theory and practice are the same, but "Join the story...
Ride Ural."
 in practice, theory and practice are different."




On 7/11/07 1:12 PM, "Kris Buelens" <[EMAIL PROTECTED]> wrote:

This is not related the size of a minidisk, but the size of a
DisContiguous Saved Segment, a piece of virtual storage, in this case shared
between CP (that stores the performance data in it ) and PERFSVM that
retrieves them out of it.

It is created by issuing DEFSEG MONDCSS sss-eee SC   (I'm a bit uncertain
about "SC")
followed by  SAVESEG MONDCSS
sss end eee are the hex starting page address and ending address
You can issue Q NSS NAME MONDCSS MAP to find its current size.
To have the new version active, all users of it should be stopped.  Q NSS
USERS MONDCSS will show the current users, CP itself will not be listed, but
if you issue MONITOR STOP, CP will stop using it too.

2007/7/11, RPN01 <[EMAIL PROTECTED]>:

We've been running PerfKit for quite some time, and the 191 disk got too
small for the trend data. I brought down both PERFSVM virtual machines (we
run two CECs and CSE), created new, larger disks, and set up the PERFSVM's
to use them, and then xautolog'ed both PERFSVMs.

Now, both are getting the message "FCXPMN446E Incomplete monitor data:
DCSS size too small".

The current data was just copied from one disk to another; what does the
DCSS size have to do with that? If the DCSS is too small, what is the
yardstick needed to decide how big to make it?

Re: PIPEDDR

[Jim Bohnsack]

The FCOPY PACKAGE on the VM Download page has this in the help file 
relating to the PACK option.


PACK Compresses  data  within  the  file  using  the  TERSE  
compaction
algorithms.  (Note: SPACK option also accepted for 
compatibility)
  


Of course the source for FCOPY isn't included (if I remember correctly).

Jim

--
Jim Bohnsack
Cornell University
(607) 255-1760
[EMAIL PROTECTED]

Re: Trouble with COPYFILE to shorten Record

[Stracka, James (GTI)]

Jim,
 
Thank you.  Just what I need.
 
Jim

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Hughes, Jim - OIT
Sent: Wednesday, July 11, 2007 3:11 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Trouble with COPYFILE to shorten Record



Pipe <   fn ft fm   |pad 13 | chop 13 | > fn ft fm

 


Jim Hughes
603-271-5586
"There's no sense in being precise when you don't even know what
you're talking about."
John von Neumann 


  _  


From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Stracka, James (GTI)
Sent: Wednesday, July 11, 2007 3:08 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Trouble with COPYFILE to shorten Record

 

I am trying to copy a file with the LRECL option to shorten it. 

e.g. 

Filename Filetype Fm Format LreclRecords 
TXJIMFILELIST A0 V169   4920 

COPYFILE TXJIM FILELIST A SORTER FILELIST A (LRECL 13 

I expected the result to be a file with LRECL 13 but it is: 

Filename Filetype Fm Format Lrecl 
SORTER   FILELIST A0 V169 

I need to do this soon.  The file is too big to use XEDIT in a
2G machine. 

Anybody have a PIPE to do this. 

Note:  The real file is hexadecimal data, not text. 

Jim 


  _  


This message w/attachments (message) may be privileged,
confidential or proprietary, and if you are not an intended recipient,
please notify the sender, do not use or share it and delete it. Unless
specifically indicated, this message is not an offer to sell or a
solicitation of any investment products or other financial product or
service, an official confirmation of any transaction, or an official
statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may
monitor, review and retain e-communications (EC) traveling through its
networks/systems. The laws of the country of each sender/recipient may
impact the handling of EC, and EC may be archived, supervised and
produced in countries other than the country in which you are located.
This message cannot be guaranteed to be secure or error-free. This
message is subject to terms available at the following link:
http://www.ml.com/e-communications_terms/. By messaging with Merrill
Lynch you consent to the foregoing.


  _  

Re: Performance Toolkit: DCSS size too small

[RPN01]

Update: Increasing the virtual memory size of the PERFSVM userid solved the
problem. I wish PerfKit gave more useful messages I¹ve been chasing the
wrong problem all day.

-- 
   .~.Robert P. Nix Mayo Foundation
   /V\RO-OE-5-55  200 First Street SW
 / ( ) \  507-284-0844   Rochester, MN 55905
^^-^^   - 
"In theory, theory and practice are the same, but ³Join the story...
Ride Ural.²
 in practice, theory and practice are different."




On 7/11/07 1:12 PM, "Kris Buelens" <[EMAIL PROTECTED]> wrote:

> This is not related the size of a minidisk, but the size of a DisContiguous
> Saved Segment, a piece of virtual storage, in this case shared between CP
> (that stores the performance data in it ) and PERFSVM that retrieves them out
> of it. 
> 
> It is created by issuing DEFSEG MONDCSS sss-eee SC   (I'm a bit uncertain
> about "SC")
> followed by  SAVESEG MONDCSS
> sss end eee are the hex starting page address and ending address
> You can issue Q NSS NAME MONDCSS MAP to find its current size.
> To have the new version active, all users of it should be stopped.  Q NSS
> USERS MONDCSS will show the current users, CP itself will not be listed, but
> if you issue MONITOR STOP, CP will stop using it too.
> 
> 2007/7/11, RPN01 <[EMAIL PROTECTED]>:
>> We've been running PerfKit for quite some time, and the 191 disk got too
>> small for the trend data. I brought down both PERFSVM virtual machines (we
>> run two CECs and CSE), created new, larger disks, and set up the PERFSVM's to
>> use them, and then xautolog'ed both PERFSVMs.
>> 
>> Now, both are getting the message "FCXPMN446E Incomplete monitor data: DCSS
>> size too small".
>> 
>> The current data was just copied from one disk to another; what does the DCSS
>> size have to do with that? If the DCSS is too small, what is the yardstick
>> needed to decide how big to make it?

Re: Trouble with COPYFILE to shorten Record

[Phil Tully]

change recfm to F

Stracka, James (GTI) wrote:


I am trying to copy a file with the LRECL option to shorten it.

e.g.

Filename Filetype Fm Format LreclRecords
TXJIMFILELIST A0 V169   4920

COPYFILE TXJIM FILELIST A SORTER FILELIST A (LRECL 13

I expected the result to be a file with LRECL 13 but it is:

Filename Filetype Fm Format Lrecl
SORTER   FILELIST A0 V169

I need to do this soon.  The file is too big to use XEDIT in a 2G 
machine.


Anybody have a PIPE to do this.

Note:  The real file is hexadecimal data, not text.

Jim


This message w/attachments (message) may be privileged, confidential 
or proprietary, and if you are not an intended recipient, please 
notify the sender, do not use or share it and delete it. Unless 
specifically indicated, this message is not an offer to sell or a 
solicitation of any investment products or other financial product or 
service, an official confirmation of any transaction, or an official 
statement of Merrill Lynch. Subject to applicable law, Merrill Lynch 
may monitor, review and retain e-communications (EC) traveling through 
its networks/systems. The laws of the country of each sender/recipient 
may impact the handling of EC, and EC may be archived, supervised and 
produced in countries other than the country in which you are located. 
This message cannot be guaranteed to be secure or error-free. This 
message is subject to terms available at the following link: 
http://www.ml.com/e-communications_terms/. By messaging with Merrill 
Lynch you consent to the foregoing.





--
'in media stat virtus'
Virtue's in the middle

Re: Trouble with COPYFILE to shorten Record

[Schuh, Richard]

Add the TRUNC option; NOTRUNC is the default.

 

Regards, 
Richard Schuh 

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Stracka, James (GTI)
Sent: Wednesday, July 11, 2007 12:08 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Trouble with COPYFILE to shorten Record

 

I am trying to copy a file with the LRECL option to shorten it. 

e.g. 

Filename Filetype Fm Format LreclRecords 
TXJIMFILELIST A0 V169   4920 

COPYFILE TXJIM FILELIST A SORTER FILELIST A (LRECL 13 

I expected the result to be a file with LRECL 13 but it is: 

Filename Filetype Fm Format Lrecl 
SORTER   FILELIST A0 V169 

I need to do this soon.  The file is too big to use XEDIT in a 2G
machine. 

Anybody have a PIPE to do this. 

Note:  The real file is hexadecimal data, not text. 

Jim 



This message w/attachments (message) may be privileged, confidential or
proprietary, and if you are not an intended recipient, please notify the
sender, do not use or share it and delete it. Unless specifically
indicated, this message is not an offer to sell or a solicitation of any
investment products or other financial product or service, an official
confirmation of any transaction, or an official statement of Merrill
Lynch. Subject to applicable law, Merrill Lynch may monitor, review and
retain e-communications (EC) traveling through its networks/systems. The
laws of the country of each sender/recipient may impact the handling of
EC, and EC may be archived, supervised and produced in countries other
than the country in which you are located. This message cannot be
guaranteed to be secure or error-free. This message is subject to terms
available at the following link:
http://www.ml.com/e-communications_terms/. By messaging with Merrill
Lynch you consent to the foregoing.

Re: Trouble with COPYFILE to shorten Record

[Hughes, Jim - OIT]

Pipe <   fn ft fm   |pad 13 | chop 13 | > fn ft fm

 


Jim Hughes
603-271-5586
"There's no sense in being precise when you don't even know what you're
talking about."
John von Neumann 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Stracka, James (GTI)
Sent: Wednesday, July 11, 2007 3:08 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Trouble with COPYFILE to shorten Record

 

I am trying to copy a file with the LRECL option to shorten it. 

e.g. 

Filename Filetype Fm Format LreclRecords 
TXJIMFILELIST A0 V169   4920 

COPYFILE TXJIM FILELIST A SORTER FILELIST A (LRECL 13 

I expected the result to be a file with LRECL 13 but it is: 

Filename Filetype Fm Format Lrecl 
SORTER   FILELIST A0 V169 

I need to do this soon.  The file is too big to use XEDIT in a 2G
machine. 

Anybody have a PIPE to do this. 

Note:  The real file is hexadecimal data, not text. 

Jim 



This message w/attachments (message) may be privileged, confidential or
proprietary, and if you are not an intended recipient, please notify the
sender, do not use or share it and delete it. Unless specifically
indicated, this message is not an offer to sell or a solicitation of any
investment products or other financial product or service, an official
confirmation of any transaction, or an official statement of Merrill
Lynch. Subject to applicable law, Merrill Lynch may monitor, review and
retain e-communications (EC) traveling through its networks/systems. The
laws of the country of each sender/recipient may impact the handling of
EC, and EC may be archived, supervised and produced in countries other
than the country in which you are located. This message cannot be
guaranteed to be secure or error-free. This message is subject to terms
available at the following link:
http://www.ml.com/e-communications_terms/. By messaging with Merrill
Lynch you consent to the foregoing.

Trouble with COPYFILE to shorten Record

[Stracka, James (GTI)]

I am trying to copy a file with the LRECL option to shorten it.

e.g.

Filename Filetype Fm Format LreclRecords
TXJIMFILELIST A0 V169   4920

COPYFILE TXJIM FILELIST A SORTER FILELIST A (LRECL 13

I expected the result to be a file with LRECL 13 but it is:

Filename Filetype Fm Format Lrecl
SORTER   FILELIST A0 V169

I need to do this soon.  The file is too big to use XEDIT in a 2G
machine.

Anybody have a PIPE to do this.

Note:  The real file is hexadecimal data, not text.

Jim


This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically indicated, 
this message is not an offer to sell or a solicitation of any investment 
products or other financial product or service, an official confirmation of any 
transaction, or an official statement of Merrill Lynch. Subject to applicable 
law, Merrill Lynch may monitor, review and retain e-communications (EC) 
traveling through its networks/systems. The laws of the country of each 
sender/recipient may impact the handling of EC, and EC may be archived, 
supervised and produced in countries other than the country in which you are 
located. This message cannot be guaranteed to be secure or error-free. This 
message is subject to terms available at the following link: 
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you 
consent to the foregoing.

Re: Performance Toolkit: DCSS size too small

[RPN01]

I agree in theory, but a) PERFSVM was running just before I increased the
size of the minidisks, and gets the DCSS size too small message after
increasing the size of the minidisk. And b) increasing the size of the DCSS
hasn¹t won me any points with PERFSVM or *MONITOR either. What I¹m seeing
now is:

 10:12:00 FCXPMN446E Incomplete monitor data: DCSS  size too small
 10:13:00 FCXPMN446E Incomplete monitor data: DCSS  size too small
 10:14:00 FCXPMN446E Incomplete monitor data: DCSS  size too small
 10:15:00 FCXPMN446E Incomplete monitor data: DCSS  size too small
 10:16:00 FCXPMN446E Incomplete monitor data: DCSS  size too small
 10:23:51 FCXPMN443E IUCV connection severed by *MONITOR, rc = 44
 10:26:31 FCXPMN440E Error 41 loading MONITOR segment MONDCSS
 10:38:48 FCXPMN446E Incomplete monitor data: DCSS  size too small
 10:41:20 FCXCMS801A RC 1 for CMSSTOR OBTAIN from 80DFD5CE for 1765179 DWs
 10:41:22 FCXPER327A Insufficient storage: I/O Device data may be incomplete
 10:42:17 FCXPER327A Insufficient storage: I/O Device data may be incomplete
 10:44:13 FCXCMS801A RC 1 for CMSSTOR OBTAIN from 80DFD5CE for 1765179 DWs
 10:44:15 FCXPER327A Insufficient storage: I/O Device data may be incomplete
 10:45:30 FCXPMN443E IUCV connection severed by *MONITOR, rc = 44
 13:37:33 FCXPMN443E IUCV connection severed by *MONITOR, rc = 44
 13:44:54 FCXCMS801A RC 1 for CMSSTOR OBTAIN from 80DFD5CE for 1765179 DWs
 13:44:56 FCXPER327A Insufficient storage: I/O Device data may be incomplete

MONDCSS is currently defined as:

0057 MONDCSS  CPDCSS N/A09000  0AFFF   SC  R  2   N/A   N/A

Q NSS USERS MONDCSS shows:

FILE FILENAME FILETYPE CLASS
0057 MONDCSS  CPDCSS   R

SYSTEM   PERFSVM

I can no longer get PERFSVM to run on either system. I¹ve tried about
everything I can think of on one system, and have left the other untouched,
other than the larger 191 minidisk. Neither work, and both fail in similar
ways

Any additional thoughts? Otherwise, I¹m going to have to open an ETR.

-- 
   .~.Robert P. Nix Mayo Foundation
   /V\RO-OE-5-55  200 First Street SW
 / ( ) \  507-284-0844   Rochester, MN 55905
^^-^^   - 
"In theory, theory and practice are the same, but ³Join the story...
Ride Ural.²
 in practice, theory and practice are different."





On 7/11/07 1:12 PM, "Kris Buelens" <[EMAIL PROTECTED]> wrote:

> This is not related the size of a minidisk, but the size of a DisContiguous
> Saved Segment, a piece of virtual storage, in this case shared between CP
> (that stores the performance data in it ) and PERFSVM that retrieves them out
> of it. 
> 
> It is created by issuing DEFSEG MONDCSS sss-eee SC   (I'm a bit uncertain
> about "SC")
> followed by  SAVESEG MONDCSS
> sss end eee are the hex starting page address and ending address
> You can issue Q NSS NAME MONDCSS MAP to find its current size.
> To have the new version active, all users of it should be stopped.  Q NSS
> USERS MONDCSS will show the current users, CP itself will not be listed, but
> if you issue MONITOR STOP, CP will stop using it too.
> 
> 2007/7/11, RPN01 <[EMAIL PROTECTED]>:
>> We've been running PerfKit for quite some time, and the 191 disk got too
>> small for the trend data. I brought down both PERFSVM virtual machines (we
>> run two CECs and CSE), created new, larger disks, and set up the PERFSVM's to
>> use them, and then xautolog'ed both PERFSVMs.
>> 
>> Now, both are getting the message "FCXPMN446E Incomplete monitor data: DCSS
>> size too small".
>> 
>> The current data was just copied from one disk to another; what does the DCSS
>> size have to do with that? If the DCSS is too small, what is the yardstick
>> needed to decide how big to make it?

Re: PIPEDDR

[Huegel, Thomas]

Right, they have it all over the place, but are keeping the pipe stage for
themselves.

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Thomas Kern
Sent: Wednesday, July 11, 2007 1:40 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: PIPEDDR


And I would suspect that TPF also has a TERSE program. I would not be
surprised if somewhere in IBM/Linux there is a TERSE executable.

/Tom Kern
/301-903-2211

On Wed, 11 Jul 2007 14:29:56 -0400, Hooker, Don - OIT
<[EMAIL PROTECTED]> wrote:
>Tom, VSE *does* have a TERSE utility (at least since z/VSE 3.1).  It can
>be used on library members that are not type DUMP or PHASE.  See the
>z/VSE 3.1 System Utility Guide.


__
<< ella for Spam Control >> has removed VSE-List messages and set aside
VM-List for me
You can use it too - and it's FREE!  http://www.ellaforspam.com

Re: PIPEDDR

[Thomas Kern]

And I would suspect that TPF also has a TERSE program. I would not be
surprised if somewhere in IBM/Linux there is a TERSE executable.

/Tom Kern
/301-903-2211

On Wed, 11 Jul 2007 14:29:56 -0400, Hooker, Don - OIT
<[EMAIL PROTECTED]> wrote:
>Tom, VSE *does* have a TERSE utility (at least since z/VSE 3.1).  It can

>be used on library members that are not type DUMP or PHASE.  See the
>z/VSE 3.1 System Utility Guide.

Re: PIPEDDR

[Hooker, Don - OIT]

Tom, VSE *does* have a TERSE utility (at least since z/VSE 3.1).  It can
be used on library members that are not type DUMP or PHASE.  See the
z/VSE 3.1 System Utility Guide.

Re: Performance Toolkit: DCSS size too small

[Kris Buelens]

This is not related the size of a minidisk, but the size of a DisContiguous
Saved Segment, a piece of virtual storage, in this case shared between CP
(that stores the performance data in it ) and PERFSVM that retrieves them
out of it.

It is created by issuing DEFSEG MONDCSS sss-eee SC   (I'm a bit uncertain
about "SC")
followed by  SAVESEG MONDCSS
sss end eee are the hex starting page address and ending address
You can issue Q NSS NAME MONDCSS MAP to find its current size.
To have the new version active, all users of it should be stopped.  Q NSS
USERS MONDCSS will show the current users, CP itself will not be listed, but
if you issue MONITOR STOP, CP will stop using it too.

2007/7/11, RPN01 <[EMAIL PROTECTED]>:


 We've been running PerfKit for quite some time, and the 191 disk got too
small for the trend data. I brought down both PERFSVM virtual machines (we
run two CECs and CSE), created new, larger disks, and set up the PERFSVM's
to use them, and then xautolog'ed both PERFSVMs.

Now, both are getting the message "FCXPMN446E Incomplete monitor data:
DCSS size too small".

The current data was just copied from one disk to another; what does the
DCSS size have to do with that? If the DCSS is too small, what is the
yardstick needed to decide how big to make it?

--
   .~.Robert P. Nix Mayo Foundation
   /V\RO-OE-5-55  200 First Street SW
 / ( ) \  507-284-0844   Rochester, MN 55905
^^-^^   -
"In theory, theory and practice are the same, but "Join the story...
Ride Ural."
 in practice, theory and practice are different."



--
Kris Buelens,
IBM Belgium, VM customer support

Re: PIPEDDR

[Schuh, Richard]

Complaining to the Support Center is sometimes very effective. I
complained a couple of years ago about the requirement that dumps be
sent in COPYFILE packed format. After I gave them the numbers for one of
our dumps packed by COPYFILE vs. VMARC, and indicated that our
development network apparently wasn't the fastest thing around, they
agreed that much smaller is better. They started accepting VMARC packed
files.


Regards, 
Richard Schuh 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Wednesday, July 11, 2007 9:37 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: PIPEDDR

On Wednesday, 07/11/2007 at 12:08 EDT, Thomas Kern
<[EMAIL PROTECTED]> 
wrote:
> Yes, that is the stuff. IBM sends us TERSEd files and we have to
DETERSE
> them. On that better system that has to send more dumps to IBM there
is 
the
> TRSMAIN program to help reduce the bandwidth for dump transfer. But I 
think
> it would violate multiple IBM legalese documents for us to reverse 
engineer
> that program into a VM usable module or pipe stage.
> 
> I can understand that some code MUST be kept secret, but if it is good
> enough for one system, why isn't it good enough for the other systems 
(Does
> VSE have a TERSE program for its dumps?)?

We are investigating the issues surrounding dump compression and 
encryption for the VM environment.  It is my hope, though, that the 
solution to these problems will be more generally useful.

Of course, if you're aren't having trouble getting data to the Support 
Center, or aren't complaining (to the Support Center) if you do, then I 
guess we don't have a problem to solve, and can move on to something
else, 
eh?  ;-)

Alan Altmark
z/VM Development
IBM Endicott

Re: PIPEDDR

[Thomas Kern]

If you are restricting your solution to only dump transfer to the Support

Center then I am not interested. I have bigger problems protecting my
customer's data and getting it available at a Disaster Recovery site. 

If you are looking to add compression and encryption to the basic VM
toolkit, then I am very interested, but the Support Center is the wrong
place to complain about that. 

/Tom Kern
/301-903-2211

On Wed, 11 Jul 2007 12:37:24 -0400, Alan Altmark <[EMAIL PROTECTED]
>
wrote:
>
>We are investigating the issues surrounding dump compression and
>encryption for the VM environment.  It is my hope, though, that the
>solution to these problems will be more generally useful.
>
>Of course, if you're aren't having trouble getting data to the Support
>Center, or aren't complaining (to the Support Center) if you do, then I
>guess we don't have a problem to solve, and can move on to something els
e,
>eh?  ;-)
>
>Alan Altmark
>z/VM Development
>IBM Endicott
>
=

Re: PIPEDDR

[Adam Thornton]

On Jul 11, 2007, at 11:58 AM, Alan Altmark wrote:

Down, boy!  Down!  [I brandish a rolled-up newspaper in your general
direction]  :-)  There are issues surrounding compression and  
encryption
that have nothing to do with secure network transmission provided  
by the

SSL server.  What to do if you want to encrypt a dump on a tape for
archive purposes and you don't have an encrypting tape drive?


Who said anything about *network* transmission?

I don't really understand your question though: if your tape drive  
won't do it, then you gotta do the crypto in (possibly-coprocessor- 
assisted) software, right?  So you just encrypt each block via  
your...well, "encrypting pipeline" is the best term I can quickly  
come up with...on its way to the drive.  You just need some method of  
making sure that you don't shoeshine the drive by forcing it to wait  
for blocks, but that's a simple matter of adjusting buffer sizes (and  
if necessary buffering to disk) on the way.  Sure, you need an  
additional buffer to hold the encrypted blocks (as well as the  
plaintext blocks) and you need the overhead of the encryption  
facility, but, hey, no such thing as a free lunch.  Assuming you pick  
to standard (and correctly-implemented) ciphers, then whether you do  
the en- or decryption in hardware or software simply becomes a  
question of speed and price, not functionality.


And if you just want your data compressed, well, you were going to  
compress it before you encrypted it anyway, right (to squeeze out as  
much entropy as possible), so you just pick a null cipher and the  
same pipelining mechanism, eh?


I mean, yeah, sure, it's not really that quite easy (key management  
being the most glaring problem to me), but it does seem like there's  
a lot of common data-block-manipulation-strategy you probably could  
factor out.


Until you said it, I hadn't given any thought to using the SSL  
server in

new and creative ways to accomplish file encryption.  Hmmm..
vey interesting.   ;-)


Oh.

Well, crap.  Can we rewind so I can *charge* you for that idea?

Adam

Re: PIPEDDR

[Huegel, Thomas]

In VSE I think we still print the dumps and send them UPS... (not really).
No there is no Terse function as we are discussing in VSE.

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Thomas Kern
Sent: Wednesday, July 11, 2007 11:08 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: PIPEDDR


Yes, that is the stuff. IBM sends us TERSEd files and we have to DETERSE
them. On that better system that has to send more dumps to IBM there is the
TRSMAIN program to help reduce the bandwidth for dump transfer. But I think
it would violate multiple IBM legalese documents for us to reverse engineer
that program into a VM usable module or pipe stage. 

I can understand that some code MUST be kept secret, but if it is good
enough for one system, why isn't it good enough for the other systems (Does
VSE have a TERSE program for its dumps?)? 

/Tom Kern
/301-903-2211

On Wed, 11 Jul 2007 10:49:36 -0500, Sebastian Welton <[EMAIL PROTECTED]>
wrote:
>
>Well there's a DETERSE MODULE on the 5E5 disk but I wonder if TERSE has
>anything to do with the TRSMAIN package available for zOS systems which
>PACKs and UNPACKs data so that it is compressed (I only mentions this
>because its gets delivered in a dataset with TERSE in the name:
>PTFLCG.TERSE409.LOADLIB)
>
>Seb
>


__
<< ella for Spam Control >> has removed VSE-List messages and set aside
VM-List for me
You can use it too - and it's FREE!  http://www.ellaforspam.com

Re: PIPEDDR

[Alan Altmark]

On Wednesday, 07/11/2007 at 12:43 EDT, Adam Thornton 
<[EMAIL PROTECTED]> wrote:

> Hunh.  A transparent passthrough compression/encryption facility.
> 
> Gee, that sounds like a good idea.
> 
> It also sounds *suspiciously similar* to an extant IBM z/VM component.
> 
> Admittedly, one that I think should be performed in a CMS app rather
> than by a detour through an install-it-yourself Linux guest, but,
> well, we're all aware of each others' views on that.

Down, boy!  Down!  [I brandish a rolled-up newspaper in your general 
direction]  :-)  There are issues surrounding compression and encryption 
that have nothing to do with secure network transmission provided by the 
SSL server.  What to do if you want to encrypt a dump on a tape for 
archive purposes and you don't have an encrypting tape drive?

Until you said it, I hadn't given any thought to using the SSL server in 
new and creative ways to accomplish file encryption.  Hmmm.. 
vey interesting.   ;-)

Alan Altmark
z/VM Development
IBM Endicott

Re: PIPEDDR

[Adam Thornton]

On Jul 11, 2007, at 11:37 AM, Alan Altmark wrote:

We are investigating the issues surrounding dump compression and
encryption for the VM environment.  It is my hope, though, that the
solution to these problems will be more generally useful.


Hunh.  A transparent passthrough compression/encryption facility.

Gee, that sounds like a good idea.

It also sounds *suspiciously similar* to an extant IBM z/VM component.

Admittedly, one that I think should be performed in a CMS app rather  
than by a detour through an install-it-yourself Linux guest, but,  
well, we're all aware of each others' views on that.


Adam

Re: PIPEDDR

[Alan Altmark]

On Wednesday, 07/11/2007 at 12:08 EDT, Thomas Kern <[EMAIL PROTECTED]> 
wrote:
> Yes, that is the stuff. IBM sends us TERSEd files and we have to DETERSE
> them. On that better system that has to send more dumps to IBM there is 
the
> TRSMAIN program to help reduce the bandwidth for dump transfer. But I 
think
> it would violate multiple IBM legalese documents for us to reverse 
engineer
> that program into a VM usable module or pipe stage.
> 
> I can understand that some code MUST be kept secret, but if it is good
> enough for one system, why isn't it good enough for the other systems 
(Does
> VSE have a TERSE program for its dumps?)?

We are investigating the issues surrounding dump compression and 
encryption for the VM environment.  It is my hope, though, that the 
solution to these problems will be more generally useful.

Of course, if you're aren't having trouble getting data to the Support 
Center, or aren't complaining (to the Support Center) if you do, then I 
guess we don't have a problem to solve, and can move on to something else, 
eh?  ;-)

Alan Altmark
z/VM Development
IBM Endicott

Re: PIPEDDR

[Thomas Kern]

Yes, that is the stuff. IBM sends us TERSEd files and we have to DETERSE
them. On that better system that has to send more dumps to IBM there is t
he
TRSMAIN program to help reduce the bandwidth for dump transfer. But I thi
nk
it would violate multiple IBM legalese documents for us to reverse engine
er
that program into a VM usable module or pipe stage. 

I can understand that some code MUST be kept secret, but if it is good
enough for one system, why isn't it good enough for the other systems (Do
es
VSE have a TERSE program for its dumps?)? 

/Tom Kern
/301-903-2211

On Wed, 11 Jul 2007 10:49:36 -0500, Sebastian Welton <[EMAIL PROTECTED]> wr
ote:
>
>Well there's a DETERSE MODULE on the 5E5 disk but I wonder if TERSE has
>anything to do with the TRSMAIN package available for zOS systems which
>PACKs and UNPACKs data so that it is compressed (I only mentions this
>because its gets delivered in a dataset with TERSE in the name:
>PTFLCG.TERSE409.LOADLIB)
>
>Seb
>
=
===

Re: PIPEDDR

[Thomas Kern]

I have never been adverse to trying 'unsupported' code. I have even
convinced some management to allow 'unsupported' code for our use and for

some of our better customers. 

If you prowl through the downloads page long enough, you will find severa
l
items that sound usefull but on deeper inspection, find that they are
dependent upon the secret workings of some unavailable program. IBM shoul
d
have required from the start that ALL items on the download page be compl
ete
and with source code included. Yeah, I know IBM would never have been abl
e
to go against the OCO is really good for everyone philosophy, but we can 
dream. 

Even with those problems, the downloads page is a source of some great
programs (Mailit and Rxserver in particular) so don't give up on it. And
please add your voice to the call for the TERSE and other stages and othe
r
programs that are hinted at.
 
/Tom Kern
/301-903-2211

On Wed, 11 Jul 2007 09:43:40 -0500, Huegel, Thomas <[EMAIL PROTECTED]> wr
ote:
>The download page is a gold mine of "unreleased/unsupported" tools that 
just
>simply make life easier. I have a lot of stuff from there, and often mod
ify
>it for my specific use.
>Understanding completly that there is no gaurentee and everything is 'us
e at
>your own risk' I have no qualms about 'giving it a try' and take
>responsibility for the consequences.
>I know of shops that forbid the use of 'unsupported' software ie from th
e
>download page,I never quite understood that philosophy, but that is thie
r
>decision.
>
>The point is, if it is good enough for IBM isn't it good enough for thie
r
>customers?
>Now we(I) need to convince them to put TERSE on the download.
>

Re: PIPEDDR

[Sebastian Welton]

On Wed, 11 Jul 2007 08:44:56 -0500, Huegel, Thomas <[EMAIL PROTECTED]> wr
ote:

>On the VM download page there is a tool 'PIPEDDR'. In the description of

>this tool it mentions that it can use a 'TERSE' pipestage, then goes on 
to
>mention that this is only available on internal IBM systems .. duh !!
>Anyone know how one could get a hold of such an internal pipestage?

Well there's a DETERSE MODULE on the 5E5 disk but I wonder if TERSE has
anything to do with the TRSMAIN package available for zOS systems which
PACKs and UNPACKs data so that it is compressed (I only mentions this
because its gets delivered in a dataset with TERSE in the name:
PTFLCG.TERSE409.LOADLIB)

Seb

Performance Toolkit: DCSS size too small

[RPN01]

We¹ve been running PerfKit for quite some time, and the 191 disk got too
small for the trend data. I brought down both PERFSVM virtual machines (we
run two CECs and CSE), created new, larger disks, and set up the PERFSVM¹s
to use them, and then xautolog¹ed both PERFSVMs.

Now, both are getting the message ³FCXPMN446E Incomplete monitor data: DCSS
size too small².

The current data was just copied from one disk to another; what does the
DCSS size have to do with that? If the DCSS is too small, what is the
yardstick needed to decide how big to make it?

-- 
   .~.Robert P. Nix Mayo Foundation
   /V\RO-OE-5-55  200 First Street SW
 / ( ) \  507-284-0844   Rochester, MN 55905
^^-^^   - 
"In theory, theory and practice are the same, but ³Join the story...
Ride Ural.²
 in practice, theory and practice are different."

Re: PIPEDDR

[Rob van der Heij]

On 7/11/07, Huegel, Thomas <[EMAIL PROTECTED]> wrote:


The point is, if it is good enough for IBM isn't it good enough for thier
customers?


I'm pretty sure you don't want to have even a fraction of what IBM
thinks is good for their own employees :-)


Now we(I) need to convince them to put TERSE on the download.


With the CMS Pipelines Runtimes Library (which you also need for the
PIPEDDR package) you have already more than what IBM thinks is good...
But 'terse' is not part of that.
The Piper normally has a good reason not to put something in the
runtime library, but I don't know the motivation in this particular
case. You could ask on CMSPIP-L if you have strong desires.

Rob

Re: PIPEDDR

[Huegel, Thomas]

The download page is a gold mine of "unreleased/unsupported" tools that just
simply make life easier. I have a lot of stuff from there, and often modify
it for my specific use.
Understanding completly that there is no gaurentee and everything is 'use at
your own risk' I have no qualms about 'giving it a try' and take
responsibility for the consequences.
I know of shops that forbid the use of 'unsupported' software ie from the
download page,I never quite understood that philosophy, but that is thier
decision.

The point is, if it is good enough for IBM isn't it good enough for thier
customers?
Now we(I) need to convince them to put TERSE on the download.  

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Thomas Kern
Sent: Wednesday, July 11, 2007 9:05 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: PIPEDDR


The best way to get the TERSE stage is to become an IBMer. It is one of the
internal only stages that never make it to the customers.

/Tom Kern
/301-903-2211

--- "Huegel, Thomas" <[EMAIL PROTECTED]> wrote:

> On the VM download page there is a tool 'PIPEDDR'. In the description of
> this tool it mentions that it can use a 'TERSE' pipestage, then goes on to
> mention that this is only available on internal IBM systems .. duh !! 
> Anyone know how one could get a hold of such an internal pipestage?  
> 
>   _  
> 
> << ella for Spam Control >> has removed 11825 VSE-List messages and set
> aside 10492 VM-List for me
> You can use it too - and it's FREE!   www.ellaforspam.com
>   
> 



 


Shape Yahoo! in your own image.  Join our Network Research Panel today!
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 


__
<< ella for Spam Control >> has removed VSE-List messages and set aside
VM-List for me
You can use it too - and it's FREE!  http://www.ellaforspam.com

Re: PIPEDDR

[Thomas Kern]

The best way to get the TERSE stage is to become an IBMer. It is one of the
internal only stages that never make it to the customers.

/Tom Kern
/301-903-2211

--- "Huegel, Thomas" <[EMAIL PROTECTED]> wrote:

> On the VM download page there is a tool 'PIPEDDR'. In the description of
> this tool it mentions that it can use a 'TERSE' pipestage, then goes on to
> mention that this is only available on internal IBM systems .. duh !! 
> Anyone know how one could get a hold of such an internal pipestage?  
> 
>   _  
> 
> << ella for Spam Control >> has removed 11825 VSE-List messages and set
> aside 10492 VM-List for me
> You can use it too - and it's FREE!   www.ellaforspam.com
>   
> 



  

Shape Yahoo! in your own image.  Join our Network Research Panel today!   
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 

Re: LPR Assistance Please

[Lionel B. Dyck]

Alan - thank you - that resolved my challenge.

If I had RSCS this would not have been an issue and setting up SMTP would 
have required more 'paperwork' to register a new SMTP sender in the 
network. This now works for the limited use that I plan to use it for.

Thanks to everyone who responded.

Lionel B. Dyck, Consultant/Specialist 
Enterprise Platform Services, Mainframe Engineering 
KP-IT Enterprise Engineering, Client and Platform Engineering Services 
(CAPES) 
925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED] 
AIM: lbdyck | Yahoo IM: lbdyck 
Kaiser Service Credo: "Our cause is health. Our passion is service. We?re 
here to make lives better.? 

?Never attribute to malice what can be caused by miscommunication.? 

NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, 
you are prohibited from sharing, copying, or otherwise using or disclosing 
its contents. If you have received this e-mail in error, please notify the 
sender immediately by reply e-mail and permanently delete this e-mail and 
any attachments without reading, forwarding or saving them. Thank you. 



Alan Altmark <[EMAIL PROTECTED]> 
Sent by: The IBM z/VM Operating System 
07/10/2007 03:52 PM
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: LPR Assistance Please






On Tuesday, 07/10/2007 at 05:47 EDT, "Lionel B. Dyck" 
<[EMAIL PROTECTED]> wrote:
> I am trying to send a text file containing smtp headers and text from 
z/VM to 
> my z/OS system so that my z/OS SMTP server will pick up the file and 
deliver it 
> as e-mail. 

I didn't know you could "print" file to SMTP.  Since it is apparently 
already in BSMTP format, can't you just PUNCH (NOHEADER it to the VM SMTP 
server?

> It is working with one slight issue - the file is arriving in the z/OS 
system 
> and having carriage control inserted somewhere. 

z/OS LPD added the carriage control.  I confirmed by using the same 
options and performing a wireshark trace on my workstation.

> SERVICE TCPSMTP  PRINTER NJE CLASS=M DEST=TCPSMTP   FILTERS f 

Try "RECFMU" instead of "PRINTER".  PRINTER specifically adds a blank for 
carriage control.

Alan Altmark
z/VM Development
IBM Endicott

PIPEDDR

[Huegel, Thomas]

On the VM download page there is a tool 'PIPEDDR'. In the description of
this tool it mentions that it can use a 'TERSE' pipestage, then goes on to
mention that this is only available on internal IBM systems .. duh !! 
Anyone know how one could get a hold of such an internal pipestage?  

  _  

<< ella for Spam Control >> has removed 11825 VSE-List messages and set
aside 10492 VM-List for me
You can use it too - and it's FREE!   www.ellaforspam.com

Re: SHOW still available ?

[Kris Buelens]

Rob, only when the spool file comes from a remote system, the TAG -set by
RSCS- can be used to find the sender.  And yes, the TAG can be changed by
anyone who had the file in its RDR/PUN can fake the TAG contents to set
another sender (the data cannot be tampered with).  But, even that should be
the past since many many years: RSCS should have OPTION SETORIG in which
case RSCS will set the origin in a safe place where one can retrieve it with
DIAG F8(?).
I'm sure you know this too, but part of the audience might not.  In general:
execs should use this DIAG output to check the origin of the file instead of
using QUERY TAG

2007/7/11, Rob van der Heij <[EMAIL PROTECTED]>:


On 7/9/07, Kris Buelens <[EMAIL PROTECTED]> wrote:

> RDR-queue, PEEK, and TRANSFER back.  Drawback: this TRANSFER process
will
> change the spool file number (and if you'd LOGOFF before we can transfer
> back, the file remains in your reader).

In addition to change of the spool file number, the transfer also sets
a bit to flag the spool file as "tampered with" and cautious
installations will be concerned about it because it lets you fake the
origin of a spool file. I used to have a local mod that would not set
the bit when the user has the SETORIG directory option.

Rob
--
Rob van der Heij
Velocity Software, Inc
http://velocitysoftware.com/





--
Kris Buelens,
IBM Belgium, VM customer support

Re: SHOW still available ?

[Rob van der Heij]

On 7/9/07, Kris Buelens <[EMAIL PROTECTED]> wrote:


RDR-queue, PEEK, and TRANSFER back.  Drawback: this TRANSFER process will
change the spool file number (and if you'd LOGOFF before we can transfer
back, the file remains in your reader).


In addition to change of the spool file number, the transfer also sets
a bit to flag the spool file as "tampered with" and cautious
installations will be concerned about it because it lets you fake the
origin of a spool file. I used to have a local mod that would not set
the bit when the user has the SETORIG directory option.

Rob
--
Rob van der Heij
Velocity Software, Inc
http://velocitysoftware.com/

Re: LPR Assistance Please

[David Boyes]

> } I am trying to send a text file containing smtp headers and text
from
> z/VM
> } to my z/OS system so that my z/OS SMTP server will pick up the file
and
> } deliver it as e-mail.

I think you're trying to teach the pig to sing here - LPR isn't intended
to be a RJE utility. 

The right way to do this is to configure VM SMTP with an IPMAILERADDRESS
entry pointing to the z/OS server and punch the file to the VM SMTP, or
look into an inexpensive way to set up a NJE link. 

Re: LPR Assistance Please

[Shimon Lebowitz]

On 10 Jul 2007 at 15:30, Lionel B. Dyck wrote:

>  
> I don't have SMTP configured on z/VM so this is easier (if it would work).

I recently set up SMTP (finally!) and found it quite 
simple and fast to do. I used a very vanilla SMTP CONFIG
with nothing in it but  SMSGAUTHLIST - ENDSMSGAUTHLIST
and IPMAILERADDRESS.

I also added an exit to my DTCPARMS file for SMTP:
:NICK.SMTP  :TYPE.SERVER  :CLASS.SMTP
:EXIT.SMTPEXIT 
The SMTPEXIT EXEC runs this little pipe:
'PIPE < TCPIP DATA * |',
'NLOCATE /NSINTER/ |',
'> TCPIP DATA A'
That way my SMTP server doesn't bother with DNS
lookups, and just passes ALL mail to the previously 
mentioned IPMAILER. 
(I believe I was told here that on newer versions - I am still 
on 4.4 - this can be forced w/o playing with the DNS definitions.)

This might be easier than your fight with the CC :-)

Shimon


-- 
**
**
Shimon Lebowitzmailto:[EMAIL PROTECTED]
VM System Programmer   .
Israel Police National HQ. 
Jerusalem, Israel  phone: +972 2 542-9877  fax: 542-9308
**
**