NOT RSCS QUESTION..Different data from CCW DATA READ as guest or native.
-- Forwarded message -- From: Tom Huegel tehue...@gmail.com 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 IBMVM@listserv.uark.edu 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 DISPLAY OF CCW DATA READ FROM 4000 64 READ DEVICE CHARACTERISTICS 3990E933 900CDA00 FEF62032 16A8000F -à E9 E000E5A2 05940222 13090674 32321502 DFEE0001 06770803 007F4A00 1B35 END OF CCWS DISPLAY+ TPF Native LPAR: ztest ccws 4000 64 CSMP0097I 10.24.48 CPU-A SS-BSS SSU-BSS IS-01 CCWS0001I 10.24.48 DISPLAY OF CCW DATA READ FROM 4000 64 READ DEVICE CHARACTERISTICS 3990EC33 900CD800 F0F62032 16A8000F -à EC E000E5A2 05940222 13090674 32320602 DFEE0001 06770803 007F4A00 1B35 END OF CCWS DISPLAY+
Re: RSCS question.
I use the RSCS transmitters for UFT but the UFTD server supplied with TCPIP. When I first tried setting this up I had problems with the UFT receiver in RSCS so I gave up on that. I can help test/debug things since this process is internal to my systems and just used by systems support staff. Let me know what you want. /Tom Kern /301-903-2211 (Office) Rick Troth wrote: The UFT protocol and implementation needs to be revisitted. To be specific, I hear that there have been interoperability problems with RSCS and some of the clients. As the maintainer of one of those clients, I'd like to see it work. :-) If anyone is available to lend a hand, lemme know! Thanks. -- R; If you think there are problems with the RSCS UFT or UFTD support than please open a problem record with the support center and we will take a look. Best Regards, Les Geer IBM z/VM and Linux Development
Re: RSCS question
On Fri, 2 May 2008 16:37:19 -0700, Howard Rifkind [EMAIL PROTECTED]
wrote:
Brian, would you be good enough to share the code for the process you
mention below?
On Thu, 1 May 2008 15:20:04 -0500, Brian Nielsen
[EMAIL PROTECTED] wrote:
I recently setup an automated process to FTP to z/OS data extracted fro
m
DISKACNT's ACCOUNT files every day. No RSCS or human intervention
required.
Here is a sanitized version of the code and environment in which sanitize
d
parts have been replaced with: {comment about what should be here}
The environment is described first, followed by the code.
---
User directory for service machine:
USER {userid} LBYONLY 16M 128M G
INCLUDE IBMDFLT
MACH ESA
IPL CMS
MDISK 191 3390 {start cyl} 001 {volid} MR
MDISK 192 3390 {start cyl} 020 {volid} MR
LINK DISKACNT 191 291 RR
Service machine requirements and notes:
- all files below must reside on the {userid} 191 MDISK
- the 192 disk will hold all files created by this process
- 20 cyls for the 192 disk will hold about 20 months worth of data (for
this site, ymmv)
z/OS requirements:
- TCP/IP connection with sending side
- pre-allocated PDSE to receive FTP transfers (2 cyls holds about 150
days worth of data for this site, ymmv)
- userid for sending side to use for FTP, with authority to write into
the PDSE
General Process requirements and notes:
- VM accounting records are closed every day just before midnight (by a
scheduling service machine)
- {userid} is XAUTOLOG'd just after midnight (by a scheduling service
machine)
- PDSE members DAYdd contain the accounting data from that day of the
month
- Alternate code in BILL-DAT EXEC can name PDSE members $Ammddyy instea
d
of DAYdd
- The PDSE is self-cleaning if members are named DAYdd, but not if name
d
$Ammddyy
- PDSE member TODAY contains yesterday's accounting data (to be
processed today by a z/OS process at this site)
- The z/OS process must erase the TODAY member when it is done with it
- PDSE member $TODAY will only exist if the z/OS process didn't erase
member TODAY
- If PDSE member REQUESTS exists, it will be retrieved and later rename
d
$Rmmddyy
- The contents of the REQUESTS member is one or more lines of: mmddyy
- The sending side will send accounting data from all dates listed in
REQUESTS
- Any ACCOUNT files on DISKACNT 191 but not on {userid} 192 are
processed sent to z/OS
- An automated process for deleting old DISKACNT 191 files and {userid}
192 files needs to be implemented.
- The EXPIRE EXEC will find files older than a threshold, but currently
does nothing else.
--
PROFILE EXEC:
/* */
'set pf1 filel * * '
'set pf3 q disk'
'set pf12 retrieve'
'set pf24 retrieve forward'
'access 291 z' /* DISKACNT 191 */
'CP LINK TCPMAINT 592 592 RR' /* has FTP command */
'ACCESS 592 U'
/* If connected, prompt user for action */
connected=substr( diag(24, -1), 13, 1 ) 2
IF connected
THEN DO
say 'Press ENTER to run normally, or any input to cancel.'
pull response
IF response'' THEN EXIT 1
END
/* run the billing process */
'EXEC BILLING'
'CP LOGOFF'
BILLING EXEC:
/* This exec ties together the execs that do the sub-functions. */
'COPY FTP REQUESTS A = INPUT D (REP' /* prep the ftp commands file */
'EXEC FTP-PRD1' /* get requests file from zOS */
'EXEC BILL-CHK' /* add unprocessed files to TODO LIST *
/
'EXEC BILL-DO'/* process TODO LIST file */
'EXEC FTP-PRD1' /* send data file to zOS */
FTP REQUESTS (this has been sanitized):
cd '{fully qualified name of z/OS PDSE}'
get requests todo.list.d (replace
quit
FTP-PRD1 EXEC (this has been sanitized to remove an IP address):
/* This exec FTPs data to/from z/OS on PROD1.*/
/* FTP commands are in an input file.*/
/* FTP ouput will be saved to a file, then appended to a log.*/
fm='D'
in_file='FTP INPUT' fm
out_file='FTP OUTPUT' fm
today=DATE('U',,,'') /* get todays date as mmddyy */
ftp_log ='FTP-LOG' today fm
'FILEDEF INPUT DISK' in_file
'FILEDEF OUTPUT DISK' out_file
z_os_ip_addr='{IP address of z/OS system}'
'FTP' z_os_ip_addr
ftp_rc=rc
IF ftp_rc0
THEN say 'FTP rc='ftp_rc
'FILEDEF INPUT CLEAR'
'FILEDEF OUTPUT CLEAR'
'PIPE (ENDCHAR ?)', /* append the ftp output to the log file */
'' out_file,
'| ' ftp_log
--
BILL-CHK EXEC:
/* This exec determines which VM accounting files have not been */
/* processed yet. */
fm_new='Z'/* unprocessed files - DISKACNT 191 *
/
fm_old='D'/* processed files */
todo_fid='TODO LIST' fm_old
yesterday_fid='YESTERDY LIST'
Re: RSCS question
On Thu, 1 May 2008 17:00:57 -0400, David Boyes [EMAIL PROTECTED] wrote: It's also your best route to move files, print and monitoring data over to other IBM OSes like z/OS (and non-IBM systems with a little help from us) without human intervention. I recently setup an automated process to FTP to z/OS data extracted from DISKACNT's ACCOUNT files every day. No RSCS or human intervention required. Brian Nielsen You *can* do FTP to solve the problem. It's just a lot more work handling all the possible problems that FTP can have -- which are legion -- in a reliable programmatic way. Without being critical, does your process handle disk full on the other end? Changed password on the remote userid (note that RSCS doesn't need a live user login on the remote system at all, FTP does if you're not using anon FTP)? Allocation failures on z/OS? FTP doesn't give you an easy way to deal with that, and if the FTP fails, you have to worry about retrying later, etc. If you handled all those problems, then you're way ahead of the game, but it's a lot of work, as you already know. No offense taken. The data transfered is stored into members of a pre- allocated PDSE. Naming conventions for the member names eventually overwrite old members so it's self-cleaning and PDSE's do not required periodic compressing like normal PDS's do. The FTP userid is dedicated t o this internal process. Changing its password would require human intervention in the first place, but would be a problem if it was done without planning and communication. Resending of data is accomplished by the z/OS side putting a REQUEST member in the PDSE with the dates of the data that need to be resent. Th e sending side always tried to download this member and includes any requested data along with any data it hasn't already tried to send. This process also works identically from non-VM platforms (ie. sending VMWARE accounting data to z/OS) for which using RSCS is not an option. Compare with: SENDFILE FOO ACCT A TO BAR AT ZOS. Fire and forget. Immediate feedback (rc ^=0) if you don't have sufficient spool to hold the file. No remote login required. Automatic retry until the file is sent. No remote disk allocation needed. You also don't have to invent ways to detect the file arriving; most job scheduling packages already know how to trigger on NJE file arrival out of the box. I'm not saying NJE is the only way to transfer files. It's sure easier to do than the alternatives, especially now that you can do it to non-IBM systems. Brian Nielsen
Re: RSCS question
This process also works identically from non-VM platforms (ie. sending VMWARE accounting data to z/OS) for which using RSCS is not an option. Actually, there are TCPNJE services for VMWare, but I can see the point. Nifty setup.
Re: RSCS question
Brian, would you be good enough to share the code for the process you mention below?--- On Thu, 5/1/08, Brian Nielsen [EMAIL PROTECTED] wrote:From: Brian Nielsen [EMAIL PROTECTED]Subject: Re: RSCS questionTo: IBMVM@LISTSERV.UARK.EDUDate: Thursday, May 1, 2008, 4:20 PMOn Wed, 30 Apr 2008 11:33:35 -0400, David Boyes [EMAIL PROTECTED] wrote:It's also your best route to move files, print and monitoring data overto other IBM OSes like z/OS (and non-IBM systems with a little help fromus) without human intervention. I recently setup an automated process to FTP to z/OS data extracted from DISKACNT's ACCOUNT files every day. No RSCS or human intervention required.Brian Nielsen Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Re: RSCS question
On Wed, 30 Apr 2008 11:33:35 -0400, David Boyes [EMAIL PROTECTED] wrote: It's also your best route to move files, print and monitoring data over to other IBM OSes like z/OS (and non-IBM systems with a little help from us) without human intervention. I recently setup an automated process to FTP to z/OS data extracted from DISKACNT's ACCOUNT files every day. No RSCS or human intervention required. Brian Nielsen
Re: RSCS question
It's also your best route to move files, print and monitoring data over to other IBM OSes like z/OS (and non-IBM systems with a little help from us) without human intervention. I recently setup an automated process to FTP to z/OS data extracted from DISKACNT's ACCOUNT files every day. No RSCS or human intervention required. Brian Nielsen You *can* do FTP to solve the problem. It's just a lot more work handling all the possible problems that FTP can have -- which are legion -- in a reliable programmatic way. Without being critical, does your process handle disk full on the other end? Changed password on the remote userid (note that RSCS doesn't need a live user login on the remote system at all, FTP does if you're not using anon FTP)? Allocation failures on z/OS? FTP doesn't give you an easy way to deal with that, and if the FTP fails, you have to worry about retrying later, etc. If you handled all those problems, then you're way ahead of the game, but it's a lot of work, as you already know. Compare with: SENDFILE FOO ACCT A TO BAR AT ZOS. Fire and forget. Immediate feedback (rc ^=0) if you don't have sufficient spool to hold the file. No remote login required. Automatic retry until the file is sent. No remote disk allocation needed. You also don't have to invent ways to detect the file arriving; most job scheduling packages already know how to trigger on NJE file arrival out of the box. I'm not saying NJE is the only way to transfer files. It's sure easier to do than the alternatives, especially now that you can do it to non-IBM systems. -- db
Re: RSCS question
We do the same, but instead rely on virtual tapes. That way we can set the retention period, and can retrieve the data for further investigation without them having deleted a disk data set. BTW, we also added some sanity check processing before writing to tape. E.g. do we have at least nn records?, do the records make sense?, etc. If those tests fail, it generates an automatic e-mail so that we are alerted to fix the problem. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Brian Nielsen [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 05/01/2008 03:20 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: RSCS question On Wed, 30 Apr 2008 11:33:35 -0400, David Boyes [EMAIL PROTECTED] wrote: It's also your best route to move files, print and monitoring data over to other IBM OSes like z/OS (and non-IBM systems with a little help from us) without human intervention. I recently setup an automated process to FTP to z/OS data extracted from DISKACNT's ACCOUNT files every day. No RSCS or human intervention required. Brian Nielsen 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. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
RSCS question
We are doing a z/VM and zLinux proof of concept and are starting gather prices for presentation to management. The trial z/VM software from IBM and the price quote contain RSCS and I'm trying to determine exactly what it is used for. From http://www.vm.ibm.com/networking/ it is explained to be a networking program. It has never been enabled: q product Product StateDescription 5VMDIR30 Enabled 01/31/08.13:55:24.MAINTInstall/service DirMaint using minidisk 5VMPTK30 Enabled 04/08/08.14:25:44.MAINTPERFKIT Minidisk Install and Service 5VMRAC30 Disabled 00/00/00.00:00:00.$BASEDDR RACF for VM 5VMRSC30 Disabled 00/00/00.00:00:00.$BASEDDR RSCS Networking Version 5 Release 3 Modification 0 so I'm wondering what it is really used for? Thanks Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474
Re: RSCS question
If you run multiple systems, it's an easy way to move files across CTC connections. If you want to be able to print to various types of printers, you may or may not need to get an RSCS license, depending on the type of printer (TCP/IP attached printers are supported w/o a license, I think. We have licensed it to use along side of CSE to couple our two machines together. DirMaint uses it to move requests from one system to the other. This could also be done via shared spool. If you're looking at a CSE environment, you'll also need PVM as well. -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ In theory, theory and practice are the same, but in practice, theory and practice are different. On 4/30/08 10:04 AM, Bauer, Bobby (NIH/CIT) [E] [EMAIL PROTECTED] wrote: We are doing a z/VM and zLinux proof of concept and are starting gather prices for presentation to management. The trial z/VM software from IBM and the price quote contain RSCS and I'm trying to determine exactly what it is used for. From http://www.vm.ibm.com/networking/ it is explained to be a networking program. It has never been enabled: q product Product StateDescription 5VMDIR30 Enabled 01/31/08.13:55:24.MAINTInstall/service DirMaint using minidisk 5VMPTK30 Enabled 04/08/08.14:25:44.MAINTPERFKIT Minidisk Install and Service 5VMRAC30 Disabled 00/00/00.00:00:00.$BASEDDR RACF for VM 5VMRSC30 Disabled 00/00/00.00:00:00.$BASEDDR RSCS Networking Version 5 Release 3 Modification 0 so I'm wondering what it is really used for? Thanks Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474
Re: RSCS question
We are doing a z/VM and zLinux proof of concept and are starting gather prices for presentation to management. The trial z/VM software from IBM and the price quote contain RSCS and I'm trying to determine exactly what it is used for. From http://www.vm.ibm.com/networking/ it is explained to be a networking program. It has never been enabled: q product so I'm wondering what it is really used for? If you don't have a channel-attached printer, it's your only IBM-recommended option for getting printed output from the VM system to a network printer (you could still use LPSERVE, but you really, really DON'T want to do that). It's also your best route to move files, print and monitoring data over to other IBM OSes like z/OS (and non-IBM systems with a little help from us) without human intervention. If you plan to use CSE for VM failover, you need it to move updates between primary and satellite DIRMAINTs. If you can afford it, RSCS is handy to have. -- db
Re: RSCS question
On Wednesday, 04/30/2008 at 11:38 EDT, David Boyes [EMAIL PROTECTED] wrote: If you plan to use CSE for VM failover, you need it to move updates between primary and satellite DIRMAINTs. Only if you're not using shared spool. Alan Altmark z/VM Development IBM Endicott
Re: RSCS question
Yet it also states: Remote Spooling Communications Subsystem (RSCS) V3.2.0 (5684-096) has bee n repackaged and is now available for licensing under International Program License Agreement (IPLA) terms and conditions. RSCS Function Level 530 (FL530) is available as a priced, optional, preinstalled feature of z/VM V5.3. So, what is it? Based on this entry I'd say nothing has changed and we ca n still have RSCS functionality. Perhaps a different function level but as long as it provides the same functions I don't care about a version number. But, as Ron pointed out, if RSCS is no longer available on zVM then I'd have to order zVM asap. Regards, Berry.
Re: RSCS question
Remote Spooling Communications Subsystem (RSCS) V3.2.0 (5684-096) has been repackaged and is now available for licensing under International Program License Agreement (IPLA) terms and conditions. RSCS Function Level 530 (FL530) is available as a priced, optional, preinstalled feature of z/VM V5.3. So, what is it? Based on this entry I'd say nothing has changed and we can still have RSCS functionality. Perhaps a different function level but as long as it provides the same functions I don't care about a version number. But, as Ron pointed out, if RSCS is no longer available on zVM then I'd have to order zVM asap. RSCS is and will continue to be available for all supported z/VM releases. If you are on z/VM 5.2, RSCS 3.2 is available. Note, z/VM 5.2 end of service is now one year away (April 30, 2009). If you are on z/VM 5.3, RSCS Function Level 5.3.0 is available. Same product, different pricing / licensing agreement. Best Regards, Les Geer IBM z/VM and Linux Development
Re: RSCS question
And do the lpr/lpd and UTF functions still work if RSCS is unlicensed? Mike Harding, Consultant/Specialist The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 04/28/2008 04:50:49 AM: RSCS is and will continue to be available for all supported z/VM releases. If you are on z/VM 5.2, RSCS 3.2 is available. Note, z/VM 5.2 end of service is now one year away (April 30, 2009). If you are on z/VM 5.3, RSCS Function Level 5.3.0 is available. Same product, different pricing / licensing agreement. Best Regards, Les Geer IBM z/VM and Linux Development
Re: RSCS question
And do the lpr/lpd and UTF functions still work if RSCS is unlicensed? There is no change. The drivers that were no-charge with the RSCS product are still no-charge with the RSCS feature. Jim
RSCS question
We are looking at possibly ordering RSCS for it's TCPNJE functions. I've been told to order it now before 9/2008 (looks like 5/2008 now). Why is that date important? I see that the standalone version is being withdraw n from support. Thanks... the curious one. Robert
Re: RSCS question
The RSCS web site has an announcement that says in part... The stand-alone RSCS V3.2.0 (5684-096) product was planned to be withdrawn from marketing effective September 30, 2007. However, on June 5, 2007 the planned date for RSCS V3.2.0 on z/VM V5.2 was extended and is is planned to be withdrawn from marketing effective September 30, 2008, and it is being changed again to be withdrawn from marketing effective May 26, 2008. So if you're not on z/VM 5.3 and want to add RSCS you've got until May 26 to order it. On Fri, Apr 25, 2008 at 10:47 AM, Robert Hughes [EMAIL PROTECTED] wrote: We are looking at possibly ordering RSCS for it's TCPNJE functions. I've been told to order it now before 9/2008 (looks like 5/2008 now). Why is that date important? I see that the standalone version is being withdraw n from support. Thanks... the curious one. Robert
Re: RSCS question.
PARM AUTOLOG is the converse of AUTOCR, and is indeed often not well understood. When a user is autologged, CP always stacks a console interrupt -maybe accompanied by the data that follows the linend (#) character on the XAUTOLOG command. This interrupt will satisfy the VM READ issued by CMS during its IPL. The SYSPROF EXEC is part of the game and will place the data found in the program stack. GCS at the other hand doesn't perform a console read during its default IPL. With PARM AUTOLOG you instruct GCS to issue a console read during IPL. If this is done following an XAUTOLOG, it will be satisfied by the console interrupt stacked by CP, at other times this results in a VM READ. What happens when the stacked console interrupt isn't read? With IPL CMS PARM AUTOCR, you tell CMS not to perform the normal console read, however unless the PROFILE EXEC set AUTOREAD OFF, at the end of the PROFILE EXEC, CMS does perform a console read and will find the data (and executes that as a CMS command). With SET AUTOREAD OFF, CMS will not read the stacked interrupt. When the stacked console interrupt isn't read, a CP SEND userid will be refused by CP with user has console input waiting. This can be solved by issuing CP SEND CP userid ATTN, what tells CMS to read its console. 2008/2/5, Schuh, Richard [EMAIL PROTECTED]: Then I guess it is time for an RCF suggesting that the RSCS manual be updated with that statement. Thanks. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel,Thomas Sent: Monday, February 04, 2008 2:08 PM To:IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCSquestion. Fromthe GCS manual. Note: PARMAUTOLOG will not work properlyif you try to enter it from an IPL instruction on your console's command line.Use PARM AUTOLOG only indirectory entries. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Schuh, Richard Sent: Monday, February 04, 2008 3:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: RSCS question. In the planning manual, there is a note about specifying PARM AUTOLOG on the IPL statement in the RSCS directory entry that says, Required if GCS is autologged. This is a bit ambiguous. GCS is autologged, but after the system has been up for a bit, if you try to execute the command CP IPL GCS PARM AUTOLOG on the machine (after all, GCS was autologged, just not immediately before RSCS was recycled), RSCS fails to start. Remove the PARM AUTOLOG, and everything works normally. Is this working as it is supposed to and the document in need of an RCF, or is this a bug? Regards, Richard Schuh -- Kris Buelens, IBM Belgium, VM customer support
Re: RSCS question.
I think you meant the analog for instead of the converse for. A converse relationship is a reverse one. As indicated, the RSCS documentation is less than crystal-clear on the topic. For example, GCS is both the name of a virtual machine (the GCS recovery machine) and of an operating system. What was really meant was if RSCS was autologged (substitute the name of any machine in the GCS group for RSCS), not if GCS was autologged. You autolog a machine, not an operating system. (Hmmm, I have never tried to autolog z/OS 1.7; maybe it will work.) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Tuesday, February 05, 2008 12:14 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS question. PARM AUTOLOG is the converse of AUTOCR, and is indeed often not well understood.
Re: RSCS question.
You autolog a machine, not an operating system. (Hmmm, I have never tried to autolog z/OS 1.7; maybe it will work.) I don't know anything about z/OS, but I can autolog a virtual machine that runs z/VSE and it works just fine. We do it with our tech support z/VSE system all the time since no one needs access to the real console. Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: RSCS question.
Again, you autolog the machine, not the operating system. For example, if a virtual machine named GLORP ipls CMS and is autologged, it is GLORP that is autologged, not CMS. Imagine the confusion that would exist if you autologged the O/S. We have, at almost any given time, some 200 virtual machines that have been autologged. Of these, 3 will be in the GCS group, 100 or more will IPL CMS and the rest will IPL TPF from a virtual device address. It would not be very meaningful, and certainly the intent would not be too clear, if I entered the command autolog 4000 to bring up a TPF guest. (Which test image? We have over 20 of them. What userid?) It makes no sense to state that x must be done when y IS AUTOLOGGED and must not be done if y is not autologged if y is the name of an operating system instead of a virtual machine. You can autolog a virtual machine that is capable of IPLing any operating system that will run on the bare metal and some that cannot. GCS and CMS fall into the latter category. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed Zell Sent: Tuesday, February 05, 2008 8:46 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS question. You autolog a machine, not an operating system. (Hmmm, I have never tried to autolog z/OS 1.7; maybe it will work.) I don't know anything about z/OS, but I can autolog a virtual machine that runs z/VSE and it works just fine. We do it with our tech support z/VSE system all the time since no one needs access to the real console. Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: RSCS question.
I still say it is the converse: - PARM AUTOCR tells CMS NOT to read the console during IPL - PARM AUTOLOG tells GCS it MUST read the console during IPL 2008/2/5, Schuh, Richard [EMAIL PROTECTED]: I think you meant the analog for instead of the converse for. A converse relationship is a reverse one. As indicated, the RSCS documentation is less than crystal-clear on the topic. For example, GCS is both the name of a virtual machine (the GCS recovery machine) and of an operating system. What was really meant was if RSCS was autologged (substitute the name of any machine in the GCS group for RSCS), not if GCS was autologged. You autolog a machine, not an operating system. (Hmmm, I have never tried to autolog z/OS 1.7; maybe it will work.) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Tuesday, February 05, 2008 12:14 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS question. PARM AUTOLOG is the converse of AUTOCR, and is indeed often not well understood. -- Kris Buelens, IBM Belgium, VM customer support
Re: RSCS question.
From the GCS manual. Note: PARM AUTOLOG will not work properly if you try to enter it from an IPL instruction on your console's command line. Use PARM AUTOLOG only in directory entries. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Schuh, Richard Sent: Monday, February 04, 2008 3:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: RSCS question. In the planning manual, there is a note about specifying PARM AUTOLOG on the IPL statement in the RSCS directory entry that says, Required if GCS is autologged. This is a bit ambiguous. GCS is autologged, but after the system has been up for a bit, if you try to execute the command CP IPL GCS PARM AUTOLOG on the machine (after all, GCS was autologged, just not immediately before RSCS was recycled), RSCS fails to start. Remove the PARM AUTOLOG, and everything works normally. Is this working as it is supposed to and the document in need of an RCF, or is this a bug? Regards, Richard Schuh
Re: RSCS question.
Then I guess it is time for an RCF suggesting that the RSCS manual be updated with that statement. Thanks. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Monday, February 04, 2008 2:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS question. From the GCS manual. Note: PARM AUTOLOG will not work properly if you try to enter it from an IPL instruction on your console's command line. Use PARM AUTOLOG only in directory entries. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Schuh, Richard Sent: Monday, February 04, 2008 3:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: RSCS question. In the planning manual, there is a note about specifying PARM AUTOLOG on the IPL statement in the RSCS directory entry that says, Required if GCS is autologged. This is a bit ambiguous. GCS is autologged, but after the system has been up for a bit, if you try to execute the command CP IPL GCS PARM AUTOLOG on the machine (after all, GCS was autologged, just not immediately before RSCS was recycled), RSCS fails to start. Remove the PARM AUTOLOG, and everything works normally. Is this working as it is supposed to and the document in need of an RCF, or is this a bug? Regards, Richard Schuh
