On Tuesday, 03/08/2011 at 01:27 EST, Ron Schmiedge
wrote:
> Also risking the wrath of Chuckie, I can tell you what the person on
> IBMLink told me when I opened an ETR for this same request:
>
> I added my second stack to SYSTEM DTCPARMS:
>
> :nick.TCPIP2 :type.server
> :class.stack
> :attach
On Tuesday, 03/08/2011 at 06:14 EST, "Gary M. Dennis"
wrote:
> If a z/VM guest partially or completely purges the TLB on a z10 or z196,
is the
> time required to quiesce CPs to coordinate the requested purge counted
toward
> total CPU time for the guest requesting the purge? If so does the gu
If a z/VM guest partially or completely purges the TLB on a z10 or z196, is
the time required to quiesce CPs to coordinate the requested purge counted
toward total CPU time for the guest requesting the purge? If so does the
guest requesting the purge get tagged for all the CPU time required to
coor
Indeed. I just polished off my resume. Chris has it, so I guess he
didn't think I needed to see your presentation. But if it's no
trouble, I would like to see what tips you have that might improve the
rascal. And thanks for SHARing. :-)
On Tue, Mar 8, 2011 at 5:33 PM, Joe Gallaher wrote:
> RE
Joe,
I would also like a copy.
Thank you, Dave
Dave Hansen
Eagan Software Systems Branch
651-406-1208
dave.l.han...@usps.gov
Dave Hansen
-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf
Of Robert Payne
Sent: Tuesday, M
I would really like to get a copy !
THANKS !
rpa...@tad.org
or
bubba...@embarqmail.com
-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU]On
Behalf Of Joe Gallaher
Sent: Tuesday, March 08, 2011 4:33 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Writing a
RE: http://share.confex.com/share/116/webprogram/Session8903.html
I sent sent out my Anaheim SHARE powerpoint slides today to everyone who
requested them. Since there were quite a few, I could have missed somebo
dy.
If you did not get them, or would like them, please let me know.
Joe
j...@spci
On Tuesday, 03/08/2011 at 02:42 EST, Tom Huegel
wrote:
> It is an issue -when tpf sees an 3990EC ? is sees the volume as a
control
> unit that supports TPF record cache. When it sees the volume as
3990E9,
> TPF marks the control unit as not supporting record cache and several
tpf
On 3/8/11 4:10 PM, "Shumate, Scott" wrote:
>I got the send file to work. I can receive it from the spool on z/OS
>side. Thanks for everyone's help.
If this file is eventually going to go into a job to be run on z/OS, talk
to your system automation people. Most (if not all) job scheduling tools
I got the send file to work. I can receive it from the spool on z/OS
side. Thanks for everyone's help.
Thanks
Scott
-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On
Behalf Of Mike Walter
Sent: Tuesday, March 08, 2011 2:33 PM
To: IBMVM@LISTSERV
That would be great. Can I take a look at it?
Thanks
Scott
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On
Behalf Of Kris Buelens
Sent: Tuesday, March 08, 2011 3:47 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Sending files to JES
On our VM systems, we had some processes that sent a CMS file embedded in an
MVS job. The MVS job started TSO in batch to receive the file. At last
that single job could carry multiple CMS files. As a result, the REXX code
became less than easy to read for beginners. I can dig that up, on
condi
Each of our VM systems had a minidisk on a shared pack (with CSE) that we
used to test of the target VM system was still up. To assure there was
always some LINK to this minidisk, we had it linked by quite a few service
machines (VMUTIL, RSCS, Operator, etc). The chance that all of these
service
Steve, I am afraid so! I think it will affect the z/OS DASD on the same CU. In
our case, it worked out well because all our DASD for z/VM is the on same CU.
Waheb
Waheb Boukhemis
McJunkin Red Man Corporation
Email: waheb.boukhe...@mrcpvf.com
Phone: +1-304-348-1588
Fax: +1-304-348-4902
Cell:
On 3/8/11 2:21 PM, "Ward, Mike S" wrote:
>Why not FTP it?
Simple enough: Automating NJE transfer is trivial -- NJE is
fire-and-forget in that the system daemons handle routing, retries, and
guaranteed delivery (short of someone clearing spool for some stupid
reason). If you've got the NJE connec
Thanks Alan,
It is an issue -when tpf sees an 3990EC – is sees the volume as a
control unit that supports TPF record cache. When it sees the volume as
3990E9, TPF marks the control unit as not supporting record cache and
several tpf functions are then not available.
Tom
On Tue, Mar
Use the VM SENDFILE command: SENDFILE fn ft fm TO user AT zos
On the z.OS side, use the TSO RECEIVE command to receive the file.
SENDFILE takes the original file and encodes it to fit into a series of 80 byte
cards, carrying enough metadata to reassemble the file in it's original form on
the re
Eventually you are going to find that files contain so many records
(perhaps some with very large LRECLs) that using SENDFILE is no longer
productive.
Not only that, but SENDFILE (aka TRANSMIT or XMIT on TSO) and RECEIVE have
significant CPU overhead, as they have to break "wide" files into fil
Why not FTP it?
-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On
Behalf Of Shumate, Scott
Sent: Tuesday, March 08, 2011 1:16 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Sending files to JES
I have 130 lrecl log file that is stored on operator's 19
I simply use this (at the end of the PROFILE EXEC for the user that "owns" the
VDISKS):
Do forever
Say "Staying alive, staying alive(99 hours)..."
"CP SLEEP 99 HRS"
End
I have 130 lrecl log file that is stored on operator's 191 disk. I need
to get it over to our MVS side so we can store it in mobius. It appears
since its greater than 80, I'm running into the problem described below.
If I use send file, the file is jumbled on mvs side. Hopefully this is
enough d
Hi, Scott.
The file you are trying to send is not too big, its record length
exceeds what the PUNCH command supports. The maximum record length for
the PUNCH command is 80 bytes. If what you are trying to send to z/OS
(via RSCS) is a JCL file, make sure its lrecl is 80 and its recfm is fixed.
On Tuesday, 03/08/2011 at 02:00 EST, "Shumate, Scott"
wrote:
> That works great.
>
> Now I'm running into a new problem. The file I'm sending is too big.
I get
> the following message.
>
> DMSPUN044E Record exceeds allowable maximum
>
> Any ideas how I can get around this?
If you
On Tuesday, 03/08/2011 at 11:50 EST, Tom Huegel
wrote:
> I see this descrepency between TPF native and TPF as a z/VM guest.
> Has anyone else seen this behavior?
> Is there any explaination? I have searched high and low, but can't find
an
> answer.
>
> TPF as z/VM guest:
> 3990E933 900CDA00
That works great.
Now I'm running into a new problem. The file I'm sending is too big. I
get the following message.
DMSPUN044E Record exceeds allowable maximum
Any ideas how I can get around this?
Thanks
Scott
From: The IBM z/VM Operating System
On 3/8/11 1:27 PM, "Ron Schmiedge" wrote:
>
>IIRC, the TCPIP person who led me through this was musing that they
>really should document how to do this in the manuals, since so many
>people ask the same question. I have not gone to look at the recent
>books.
Would be a nice redbook-like thing --
Our VSE lock file mdisk belongs to OPERATOR, which runs PROP and is
disconnected shortly after IPL. All VSE guests tests the lock file in
their PROFILE EXEC and if it needs to be initialized, does it. So any
guest can come up first and set up the lock file. All OPERATOR does is
have the mdisk entry
Also risking the wrath of Chuckie, I can tell you what the person on
IBMLink told me when I opened an ETR for this same request:
I added my second stack to SYSTEM DTCPARMS:
:nick.TCPIP2 :type.server
:class.stack
:attach.0C00-0C01
I created a TCPIP2 TCPIP file, whi
-- Forwarded message --
From: Tom Huegel
Date: Tue, Mar 8, 2011 at 8:48 AM
Subject: Different data from CCW DATA READ as guest or native.
To: The IBM z/VM Operating System
I see this descrepency between TPF native and TPF as a z/VM guest.
Has anyone else seen this behavior?
Is t
Hi Waheb,
I do not have this PTF installed.
Yes we are using HYPERPAV.
We have shared DASD between our z/OS and z/VM LPARs. If I turn off HYPERPAV on
my z/VM LPAR via the SET command, will that also turn off HYPERPAV effectively
on the z/OS side for those volumes on that CU ? I don't want it
On 3/8/11 1:00 PM, "Les Koehler" wrote:
>He didn't specify it was a job. That opens a whole new can of worms: JCL,
>pswd etc.
Not the problem of the NJE transport. It's just got to get the file from
system A to system B. Content and payload correctness are left as an
exercise to the sender. 8-)
On 3/8/11 12:57 PM, "Wandschneider, Scott"
wrote:
>I have a SVM called VDISKS the creates and initializes a virtual lock
>file for four VSE guest to use. After a short time, VDISKS is logged off
>by the system. All is fine if at least one VSE remains logged on,
>however if all are logged off th
The next meeting of the DC z/VM & Linux User Group ³HILLGANG² will take
place on March 16 at the CA offices in Herndon, VA. The meeting details may
be found here: http://www.vm.ibm.com/events/hill0316.pdf
Follow the directions in that document to RSVP.
Neale
Scott,
Try adding the following two (2) commands to your PROFILE EXEC --
CP SET RUN ON
SET AUTOREAD OFF
John P. Baker
Chief Software Architect
HFD Technologies
-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf
Of Wandschneider, Scott
Sent
He didn't specify it was a job. That opens a whole new can of worms: JCL, pswd
etc.
Les
David Boyes wrote:
Alternatively, the TCPNJE add-on-extra to RSCS will allow submission through
NJE.
The user part of the process is the same, though. In both cases, the file has
to end up in RSCS' virt
I have a SVM called VDISKS the creates and initializes a virtual lock file for
four VSE guest to use. After a short time, VDISKS is logged off by the system.
All is fine if at least one VSE remains logged on, however if all are logged
off the virtual lock file goes away also. How can I keep V
> Alternatively, the TCPNJE add-on-extra to RSCS will allow submission through
> NJE.
The user part of the process is the same, though. In both cases, the file has
to end up in RSCS' virtual reader; the transport between VM and z/OS is
transparent to that process.
If the z/OS system was runni
Also, Active means that the link has been started but the sign-on process has
not been completed. The status must be Connect before a file can be
transferred. Either JES has not started the link or there is a problem in the
definition on either or both ends.
Regards,
Richard Schuh
___
It should show Connect rather than Active
You have started the connection on the VM side, make sure the corresponding CTC
on the MVS side is defined to MVS as BCTC if using ESCON and then start the MVS
Line
Also make sure that the RSCS definition for the JES NODE name matches and the
buffer is t
Alternatively, the TCPNJE add-on-extra to RSCS will allow submission through
NJE.
Neale
On 3/8/11 12:34 PM, "David Boyes" wrote:
SPOOL PUN TO RSCS
TAG DEV PUN zos SYSTEM
PUNCH fn ft fm ( NOH
Explanation:
SP PUN TO RSCS sets the destination of the PUNCH command on the VM side. RSCS
knows to
SPOOL PUN TO RSCS
TAG DEV PUN zos SYSTEM
PUNCH fn ft fm ( NOH
Explanation:
SP PUN TO RSCS sets the destination of the PUNCH command on the VM side. RSCS
knows to look at the tag data of the incoming files to decide what to do with
them. TAG DEV PUN zos SYSTEM sets the tag data destination field
I'm new to the z/VM arena. I need a good place to start. I'm trying to
send a file from z/VM via RSCS to z/OS JES spool. Can someone point me
to a good starting place? I do have an RSCS connection between z/VM &
z/OS. When you display it, it shows active.
Thanks
Scott
I see this descrepency between TPF native and TPF as a z/VM guest.
Has anyone else seen this behavior?
Is there any explaination? I have searched high and low, but can't find an
answer.
TPF as z/VM guest:
ztest ccws 4000 64
CSMP0097I 10.24.33 CPU-A SS-BSS SSU-BSS IS-01
CCWS0001I 10.24.33 DIS
Alain,
The VM:Operator "primitive" command to cause the script to wait for a
given period and/or number of messages is:
"PROCESS WAIT [seconds|* [messages|1] ]
The 'TEST' before 'PROCESS WAIT' prevents an error if a nonzero return
code is issued - which is likely, as the number of message
Thanks Alan, I should have mentioned that too.
2011/3/8 Alan Altmark
> On Tuesday, 03/08/2011 at 02:51 EST, Kris Buelens
> wrote:
> > An OSA ICC is great, but costs real money: the price of that OSA card,
> it will
> > be dedicated to its OSA ICC function.
>
> To clarify, except for 10 Gb ether
On Tuesday, 03/08/2011 at 02:51 EST, Kris Buelens
wrote:
> An OSA ICC is great, but costs real money: the price of that OSA card,
it will
> be dedicated to its OSA ICC function.
To clarify, except for 10 Gb ethernet, all OSA cards have two chpids. You
assign ICC on a per-chpid basis.
Alan A
On Tuesday, 03/08/2011 at 03:18 EST, Alain Benveniste
wrote:
> I think to open a pmr for this.
ICH520I *is* somewhat misleading in a VM environment. It is from the core
RACF/MVS services engine that is started by the RACF/VM "shell". Only
after the engine is happily running will RACF connec
We went from Ramac to Shark to DS8100 no problem. We use FDRPAS to do
the copies for us.
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On
Behalf Of Nigel Salway
Sent: Monday, March 07, 2011 4:12 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Contemplating upgrading 2105-800 to DS
I thought the DS6800 was withdrawn from marketing.
On Tue, Mar 8, 2011 at 8:01 AM, Frank M. Ramaekers wrote:
> Yes, we did that and it was seamless. Best advice use fibre (and as
> many as you can afford). I don’t know if your 2105 is ESCON or Fibre
> attached.
>
>
>
>
>
> Frank M. Ramaekers
Yes, we did that and it was seamless. Best advice use fibre (and as
many as you can afford). I don't know if your 2105 is ESCON or Fibre
attached.
Frank M. Ramaekers Jr.
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On
Behalf
You should better not place a CP SLEEP in VM:Operator scripts: it will make
the whole VM operator go to wait, and when many message arrive for
VM:operator while it waits, CP's IUCV queue could get full and CP will then
throw them at the console, instead of presenting them to IUCV, where
VM:Operator
Kris
You are right
ICH520i appears before a CST and a RPI message.
If i execute my vmoperator script on the last standard message format, It works.
If I put a sleep in my script and execute it as soon as ich520i appears, it
works.
I think to open a pmr for this.
Alain
Le 8 mars 2011 à 08:38,
52 matches
Mail list logo
