All,
I have an RSCS link to an IBM 6400 dot matrix printer -
LINKDEFINE SPSKH16 TYPE TCPASCII AST FORM *
PARM SPSKH16 EXIT=ASCXONE EP='C=TCPASCII SEP=NO' ITO=0 #
PORT=9100 HOST=xxx.xx.xx.xx
We chose to use a TCPASCII type link because that seemed to be the most
suitable, and we
On Tuesday, 10/28/2008 at 11:49 EDT, Jones, Ian H [EMAIL PROTECTED]
wrote:
RSCS is restarting the link every second or so, until the users switch
their printer back on again. RSCS is probably trying to restart the link
because there is a file sitting on the queue, but I would prefer it not
I have an RSCS link to an IBM 6400 dot matrix printer -
LINKDEFINE SPSKH16 TYPE TCPASCII AST FORM *
PARM SPSKH16 EXIT=ASCXONE EP='C=TCPASCII SEP=NO' ITO=0 #
PORT=9100 HOST=xxx.xx.xx.xx
We chose to use a TCPASCII type link because that seemed to be the most
suitable, and we couldn't get
Hello all. We're bouncing around an idea to change the way we allocate Linux
guests. Currently, we have a mdisk that
has all of the Linux 191 disks on. We then have separate 200 disks (mod9's).
We're thinking of combining the two, such
that we have a 1 cylinder 191 mdisk, then 10015 cylinders for
Mary Anne Matyaz wrote:
Hello all. We're bouncing around an idea to change the way we allocate
Linux guests. Currently, we have a mdisk that
has all of the Linux 191 disks on. We then have separate 200 disks
(mod9's). We're thinking of combining the two, such
that we have a 1 cylinder 191
Small thing, we back up all of our drives, including 200's, through MVS
and then do the Linux minidisks through TSM. This allows us the ability
to easily retrieve individual files, but the MVS DASD backups are the
way to go when a Linux box goes belly up.
David Dean
Information Systems
Well, they just have a small profile exec that executes the more detailed
one off of a shared disk. So I'm ok there.
MA
On Tue, Oct 28, 2008 at 12:25 PM, Rich Smrcina [EMAIL PROTECTED] wrote:
Mary Anne Matyaz wrote:
Hello all. We're bouncing around an idea to change the way we allocate
Linux
Sorry, I see that you think I have a shared 191. I don't, I just have them
all smooshed onto
one volume, versus being on the 200 volume.
MA
On Tue, Oct 28, 2008 at 12:25 PM, Rich Smrcina [EMAIL PROTECTED] wrote:
Mary Anne Matyaz wrote:
Hello all. We're bouncing around an idea to change the
Alan Altmark replied
But if RSCS doesn't do that, it won't start promptly when they
power the printer on and you will get complaints. (I am vaguely
surprised that RSCS doesn't treat this as an auto-dial connection
and use the backoff retry facility. Maybe it's under the RESTART
If you¹re just IPLing CMS to set things up and then IPL Linux, is there
really a reason to have multiple 191 minidisks? We share a single read/only
191 minidisk among all the Linux guests, in both LPARs. They all end up
IPLing 391, and we¹ve added a piece to the profile that looks for userid()
Well, two things. I thought you had to have a writable A disk for CMS? And
we do need
a redhat.conf file on there when we kickstart the linux, not so much
afterwards.
MA
On Tue, Oct 28, 2008 at 12:45 PM, RPN01 [EMAIL PROTECTED] wrote:
If you're just IPLing CMS to set things up and then IPL
I would like to use a unique device, AA14, to connect 1stlvl with 2ndlvl.
I tried with CTC and it works inside the VMs. But I can't enter 2ndlvl wh
en
I try to connect from the global network.
I talked with the IP guy and told me it worked that way when it was coded
with LCS in place of QDIO. He
No - CMS doesn't need a writable disk to IPL..Most of the customers I've
worked with use a common disk (LNXMAINT 192, for example) that they LINK as
the guests 191:
LINK LNXMAINT 192 191 RR in the directory
For installs - you can either define a writable 191 manually with TDISK --
or
1. As has been said, you don't need a R/W disk to IPL. R/O is good. SFS
directory is even better.
2. Once you IPL Linux, you are not in CMS anymore. You won't be doing
anything with your a-disk anymore. So make it easy on your self, when you need
to make changes to the profile exec. Put
On Oct 28, 2008, at 12:32 PM, Tom Duerbusch wrote:
1. As has been said, you don't need a R/W disk to IPL. R/O is
good. SFS directory is even better.
2. Once you IPL Linux, you are not in CMS anymore. You won't be
doing anything with your a-disk anymore. So make it easy on your
self,
I'm not sure why you are using virtual CTCs. You should try to put the second
level guest and the 1st level TCPIP on a vswitch. With the vswitch connecting
via the osa the physical network both the 1st level vm tcpip and the tcpip 3rd
level in the guest will have connectivity.
Or, if you
I think the point is that once Linux boots - an A disk isn't relevant .. not
that Linux needs to read anything on the 191.
Scott Rohling
On Tue, Oct 28, 2008 at 11:48 AM, Adam Thornton [EMAIL PROTECTED]wrote:
On Oct 28, 2008, at 12:32 PM, Tom Duerbusch wrote:
1. As has been said, you don't
I must of missed the first part of the conversation
Why would you want Linux to have access to your A-disk?
There might be reasons, but inquiring minds want to know, and deleted the
original posts G.
If it is an occasional access, then the Linux guest can just FTP to/from the
SFS system.
CMS doesn¹t need a writable 191, as others have already said. Also, Linux
doesn¹t use the 191 at all, so the only moment that the 191 needs to be
stable is when the guest(s) login. This means that you can likely grab it
r/w to add things like kickstart files without affecting any of the guests.
Just curious why you think SFS is better than a 1 cylinder shared minidisk?
To me - it's a point of failure as an SFS pool server must be running just
to get to the PROFILE EXEC...
Scott Rohling
On Tue, Oct 28, 2008 at 11:32 AM, Tom Duerbusch
[EMAIL PROTECTED]wrote:
1. As has been said, you
True about another point of failure.
However, how many times a year is your SFS server(s) down?
I find an occasional crash (usually due to me) about once every year or two.
It's really a pain, as my CMS type servers, don't auto reconnect. So I have to
manually force off the servers and let
One problem w/ SFS is that we don't run it on our second LPAR at all.
Anything that we want to be able to run on both systems has to reside on a
minidisk. SFS isn't a choice.
If IBM would allow the vmsys: pool to be shared between systems, we'd be
more likely to use it.
--
Robert P. Nix
On Tuesday, 10/28/2008 at 03:28 EDT, RPN01 [EMAIL PROTECTED] wrote:
If IBM would allow the vmsys: pool to be shared between systems, we'd be
more likely to use it.
Say more. The VMSYS filepool was intended to contain information that is
used ONLY for THIS system (inventory, service, etc.).
Well - technically true if MW is used on the LINK instead of MR -- that's
such a big no no in general I guess I assume people won't do it -- but good
point.
Scott Rohling
Until you have two users, access the shared disk in
R/W mode, to update it. No protection. SFS will always protect
Robert,
You don't have to use the VMSYS filepool. You can create a new filepool
that doesn't start with VMSYS and share it between systems. The only
drawback is that if the system that hosts the filepool server isn't up,
the filepool isn't accessible to the other system.
We have filepool
On Oct 28, 2008, at 1:36 PM, Tom Duerbusch wrote:
I must of missed the first part of the conversation
Why would you want Linux to have access to your A-disk?
There might be reasons, but inquiring minds want to know, and
deleted the original posts G.
Handy for building systems where you
26 matches
Mail list logo
