Re: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
On Sat, January 19, 2013 16:22, Paul Gilmartin wrote: On Sat, 19 Jan 2013 12:24:27 +1100, Andrew Rowley wrote: A quick look at the documentation suggests that CTRLCONN might be the equivalent for the control connection. SITECTRLConn=FTP_STANDARD_TABLE LOCSITE CTRLConn=FTP_STANDARD_TABLE Thanks Andrew and gil, that works! Apparently it doesn't matter *which* code page is specified. It does matter though that the same code page is used (could even be 7BIT). Before posting, I had tried things like LOCSITE CTRLConn=IBM-285, i.e., have the client use the same code page as the server, or vice versa, and I still don't know why that wouldn't suffice. Many thanks to everyone who tried to help! Regards, Boris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM CDS size versus multi-cluster
Hi all, thx for your upds. What I have now for BCDS is: ARC0148I BCDS TOTAL SPACE=468 K-BYTES, CURRENTLY 341 ARC0148I (CONT.) ABOUT 83% FULL, WARNING THRESHOLD=85%, TOTAL ARC0148I (CONT.) FREESPACE=36%, EA=YES, CANDIDATE VOLUMES=0 ARC0948I BCDS INDEX TOTAL SPACE=126000 K-BYTES, 344 ARC0948I (CONT.) CURRENTLY ABOUT 8% FULL, WARNING THRESHOLD=85%, ARC0948I (CONT.) CANDIDATE VOLUMES=0 BCDS dsn is on a 3390-9 dasd. No other dsns reside on that disc. I still have 3.200 CYls free, I'll redefine it with more space. Many thx, A.Cecilio. On Thu, Jan 17, 2013 at 7:29 PM, O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov wrote: Lizette, What is the freespace(nn,nn) parameter in your CDS VSAM define? I suspect you are running with something like 50,50 based on your comment. If you are 96% full with 62% freespace that tells me that a section of your CDS is experiencing a lot of activity and will drive the file to 100%. Probably at the most inopportune time. Splits for a HSM CDS should not be a concern. It's not like anyone is waiting with bated breath for a migrate or backup to finish. Like any other VSAM KSDS, the HSM CDSs need to be re-organized from time to time. Thank You, Dave O'Brien NIH Contractor From: Lizette Koehler [stars...@mindspring.com] Sent: Thursday, January 17, 2013 9:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM CDS size versus multi-cluster I think if you issue the command F dfhsm,Q CDS you may find in the ARC0148I messages that there are two pieces of information to explain if your file needs to be reorg'd First is the number you get is %Full. However there is a second number %Freespace. What I have seen in my shop is we are running 96% full. However we have 62% freespace. Which to me does not indicate a need to reorg. According to IBM and Share presentations, the xCDS files should not be reorg'd. That when you reorg an xCDS HSM has to starting splitting the files again which will slow down the process for a little bit. Once enough splits occur so there is room to insert records, it is fine. So the questions are 1) Is the xCDS so big it needs a reorg? 2) Do I need to resize the xCDS dataset? Once those are answered, you can figure out when to take an outage on HSM. The other option is to change from VSAM to VSAM RLS structure for your xCDS datasets. You may also wish to review if the Journal dataset should be changed as well. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of af dc Sent: Thursday, January 17, 2013 5:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM CDS size versus multi-cluster Hello, I'm running z/os V1.12 and I've got my BCDS filled with 85%. It's size is 6500 CYLS with no SEC space. VSAM characteristics are: SHROPTNS(3,3) RECOVERY UNIQUE NOERASE UNORDERED TEMP-EXP NOREUSE NONSPANNED INDEXED NOWRITECHK NOIMBED NOREPLICAT EXTENDEDEXT-ADDR In a short time I'll have to create a new BCDS, so, in your opinion what's advisable to have (performance aspect, backup considerations?, etc)?? 1) a bigger BCDS or 2) multi cluster Note: - DFHSM cdss are shared among 3 lpars Any hint is welcome? Many thx, Antonio Cecilio. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS COMMAND VIA BATCH
H Boris,
I'm not understanding why I'm getting the following error:
# of MVS commands to issue: 1
Issuing command #1...
DISPLAY SMS
11.50.35 IGD029I ERROR FOR DISPLAY SMS COMM 137
11.50.35 ERROR IS EMBEDDED BLANKS BETWEEN OPERANDS OF COMMAND
READY
END
however it worked on:
# of MVS commands to issue: 1
Issuing command #1...
D U,,,03C1,4
11.44.55 IEE457I 11.44.55 UNIT STATUS 433
11.44.55 UNIT TYPE STATUSVOLSER VOLSTATE
11.44.55 03C1 359L O-NRD -AS /REMOV
11.44.55 03C2 359L O-NRD -ASI00340 PRIV/REMOV
11.44.55 03C3 359L O-NRD -ASI00082 PRIV/REMOV
11.44.55 03C4 359L O-NRD -AS /REMOV
READY
END
Can you pls geve me an hint ??
Many thx, A.Cecilio.
On Thu, Jan 17, 2013 at 4:23 PM, Boris Lenz boris.l...@ims.sells.ch wrote:
John,
your command wasn't found because VARY is an MVS command, not a TSO
command, and IKJEFT01 is TSO.
If, as others pointed out, the // COMMAND suggestion doesn't work due to
authorization issues or timing issues, you may want to try it in TSO batch
again, using the CONSOLE command (for which you're authorized maybe).
Something like this:
//your-jobcard JOB ...
//STEP01EXEC PGM=IEBUPDTE,PARM=NEW
//SYSPRINT DD DUMMY
//SYSUT2DD DISP=(,PASS),SPACE=(TRK,(1,1)),
// RECFM=FB,LRECL=80,DSORG=PO,DSNTYPE=LIBRARY
//SYSIN DD DATA,DLM='¬¬'
./ ADD NAME=MVSCMD
/* rexx */
/* issues MVS commands */
arg dd
call ReadInput
if result ^= 0 then exit result
call CountCmds
say # of MVS commands to issue: result
cartpfx = userid
cartcnt = 0
address tso
do k = 1 to inplines.0
CONSOLE ACTIVATE NAME(useridZ)
'CONSPROF SOLDISP(NO) UNSOLDISP(NO) SOLNUM(1024) UNSOLNUM(1024)'
conscmd = inplines.k
'CONSOLE SYSCMD('conscmd') CART('conscart')'
gc = getmsg('R.','SOL',conscart,,5)
if gc = 4 then gc = getmsg('R.','EITHER',conscart,,5)
if gc = 0 then do
say Issuing command #k...
say conscmd
do i = 1 to r.0
conscmdn = r.mdbgtimh r.i
say conscmdn
end
if gc 0 then say 'Unable to retrieve message - GETMSG RC:' gc
end
'CONSPROF SOLDISP(YES) UNSOLDISP(YES) SOLNUM(1000) UNSOLNUM(1000)'
'CONSOLE DEACTIVATE'
end
exit
/**/
CountCmds: procedure expose inplines.
j = 0
do i = 1 to inplines.0
if (left(inplines.i,2) ^= amp;) then j=j+1
end
return j
/**/
ReadInput: procedure expose dd inplines.
maxcc = 0
address mvs EXECIO * DISKR dd (STEM INPLINES. FINIS
if rc ^= 0 then do
say RXLENZ01 ERROR READING INPUT FROM DD dd
maxcc = 16
end
if inplines.0 = 0 then do
say RXLENZ02 NO INPUT PROVIDED IN DD dd
maxcc = 16
end
return maxcc
/**/
¬¬
//*
//STEP02EXEC PGM=IKJEFT01,PARM='%MVSCMD MVSCMDS'
//SYSEXEC DD DSN=*.STEP01.SYSUT2,DISP=(OLD,DELETE)
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
//MVSCMDS DD *
VARY SMS,VOLUME(SMC1G5),DISABLE,NEW
//
Regards,
Boris
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS COMMAND VIA BATCH
It is telling you that you have embedded blanks between operands, some like
this: D SMS (two blanks between D and SMS). Or what is COMM following SMS?
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of af dc
Sent: Monday, January 21, 2013 6:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMS COMMAND VIA BATCH
H Boris,
I'm not understanding why I'm getting the following error:
# of MVS commands to issue: 1
Issuing command #1...
DISPLAY SMS
11.50.35 IGD029I ERROR FOR DISPLAY SMS COMM 137
11.50.35 ERROR IS EMBEDDED BLANKS BETWEEN OPERANDS OF COMMAND READY END
however it worked on:
# of MVS commands to issue: 1
Issuing command #1...
D U,,,03C1,4
11.44.55 IEE457I 11.44.55 UNIT STATUS 433
11.44.55 UNIT TYPE STATUSVOLSER VOLSTATE
11.44.55 03C1 359L O-NRD -AS /REMOV
11.44.55 03C2 359L O-NRD -ASI00340 PRIV/REMOV
11.44.55 03C3 359L O-NRD -ASI00082 PRIV/REMOV
11.44.55 03C4 359L O-NRD -AS /REMOV
READY
END
Can you pls geve me an hint ??
Many thx, A.Cecilio.
On Thu, Jan 17, 2013 at 4:23 PM, Boris Lenz boris.l...@ims.sells.ch wrote:
John,
your command wasn't found because VARY is an MVS command, not a TSO
command, and IKJEFT01 is TSO.
If, as others pointed out, the // COMMAND suggestion doesn't work due
to authorization issues or timing issues, you may want to try it in
TSO batch again, using the CONSOLE command (for which you're authorized
maybe).
Something like this:
//your-jobcard JOB ...
//STEP01EXEC PGM=IEBUPDTE,PARM=NEW
//SYSPRINT DD DUMMY
//SYSUT2DD DISP=(,PASS),SPACE=(TRK,(1,1)),
// RECFM=FB,LRECL=80,DSORG=PO,DSNTYPE=LIBRARY
//SYSIN DD DATA,DLM='¬¬'
./ ADD NAME=MVSCMD
/* rexx */
/* issues MVS commands */
arg dd
call ReadInput
if result ^= 0 then exit result
call CountCmds
say # of MVS commands to issue: result cartpfx = userid cartcnt = 0
address tso do k = 1 to inplines.0 CONSOLE ACTIVATE NAME(useridZ)
'CONSPROF SOLDISP(NO) UNSOLDISP(NO) SOLNUM(1024) UNSOLNUM(1024)'
conscmd = inplines.k
'CONSOLE SYSCMD('conscmd') CART('conscart')'
gc = getmsg('R.','SOL',conscart,,5)
if gc = 4 then gc = getmsg('R.','EITHER',conscart,,5) if gc = 0 then
do
say Issuing command #k...
say conscmd
do i = 1 to r.0
conscmdn = r.mdbgtimh r.i
say conscmdn
end
if gc 0 then say 'Unable to retrieve message - GETMSG RC:' gc end
'CONSPROF SOLDISP(YES) UNSOLDISP(YES) SOLNUM(1000) UNSOLNUM(1000)'
'CONSOLE DEACTIVATE'
end
exit
/**/
CountCmds: procedure expose inplines.
j = 0
do i = 1 to inplines.0
if (left(inplines.i,2) ^= amp;) then j=j+1
end
return j
/**/
ReadInput: procedure expose dd inplines.
maxcc = 0
address mvs EXECIO * DISKR dd (STEM INPLINES. FINIS
if rc ^= 0 then do
say RXLENZ01 ERROR READING INPUT FROM DD dd
maxcc = 16
end
if inplines.0 = 0 then do
say RXLENZ02 NO INPUT PROVIDED IN DD dd
maxcc = 16
end
return maxcc
/**/
¬¬
//*
//STEP02EXEC PGM=IKJEFT01,PARM='%MVSCMD MVSCMDS'
//SYSEXEC DD DSN=*.STEP01.SYSUT2,DISP=(OLD,DELETE)
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
//MVSCMDS DD *
VARY SMS,VOLUME(SMC1G5),DISABLE,NEW
//
Regards,
Boris
--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS COMMAND VIA BATCH
On Mon, January 21, 2013 12:53, af dc wrote: H Boris, I'm not understanding why I'm getting the following error: # of MVS commands to issue: 1 Issuing command #1... DISPLAY SMS 11.50.35 IGD029I ERROR FOR DISPLAY SMS COMM 137 11.50.35 ERROR IS EMBEDDED BLANKS BETWEEN OPERANDS OF COMMAND READY END Do you have ISPF line numbers in col 73-80? Can't think of anything else right now. The only transmission error in my REXX is in the line with if (left(inplines.i,2) (listserv translated the two ampersands). But that can't be the error in your case. Regards, Boris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 0D7 with ATSET
Jim Mulder wrote Your ATSET does a stacking PC-cp. The ATSET service routine removes secondary authority for your server's AX to your User space. ATSET tries to return via PR, but since you invoked ATSET in cross memory mode, this is PR-ss, and secondary authority checking is done. The resulting SASN would be your User spaces's ASN, and the ATSET has just removed that authority. So the PR-ss results in a program check code x'025', which z/OS turns into a 0D7-025 abend. Does this mean a Space Switching PC cannot be used to remove the users access ? Paul D'Angelo -- Original Message -- From: Jim Mulder d10j...@us.ibm.com To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 0D7 with ATSET Date: Sun, 20 Jan 2013 22:19:14 -0500 IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 01/20/2013 05:08:06 PM: From: esst...@juno.com esst...@juno.com To: IBM-MAIN@listserv.ua.edu, Date: 01/20/2013 09:53 PM Subject: 0D7 with ATSET Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu Im trying to understand why a 0D7 Abend occurs With ATSET. Im on a zos 1.7 System, developing some sample cross memory routines. I am provideing 3 sample Routines (Connect, Disconnect, and a Stacking Space Switching Service Routine) The Server Address Space The Server Address Space sets up the Cross Memory Environment for Selected Users as outlined in MVS Extended Addressability. All routines provide then minimum functionality, they have no real function. The Server Address Space creates a Name Token Pair, for passing the Space Token of the Server Address Space, the reserved Linkage Index (LX), and the Address Of the Cross Memory Service Block which resides in the Server Address Space. The Service Block contains all the Lists and Work Areas used to Establish the Cross Memory Environment (AXL, LXL,TXL) as described in MVS Extended Addressability. All progrms in the Entry Table have SASAN=OLD Specified. User Address Space The User program is bascialy a Driver facility to exercise, debug, and verify the implementaion of the Cross Memory Envoronment. I began by using Two of the three Routines (The Connection And Dsiconnect routine) as local programs. Initially, the User Program Loads the connect disconnet programs. A modeset is issued prior to issung a BASR 14,15. The connection routine would latter be converted to a Non Space Switching PC Routine and the Disconnect Routine would latter be converted to a Stacking Space Switching Routine. The User Code performs the following: Retrieve the Name Token Pair created by the Server Address Space. Load the Conection Routine Switch To Supervisor State BASR 14,15 to the Connection Routine Switch To Problem State Issue a Stacking Space Switch PC Instruction to invoke PC Routine #3 (the pseudo service) Load the Disconnect Routine Switch To Supervisor State BASR 14,15 to the Disconnect Routine Switch To Problem State The Connect And Disconnect Routines are Initially Loaded,ensuring that theses programs perform the proper functionality. Its basicaly an easy to debug. The User Routine Functions properly as outlined above. When The Connection And Disconect routines are invoked via a BASR 14,15 they function properly. The Service Routine when called by a PC instruction also executes properly. The Connection Routine - Establishs Access and Sets Up PT SSAR Authority for the User Address Space The connection Routine issues: OBTAIN STORAGE ALESERV ADD SAC 512 Swicth To Access register Mode Our PC Service Block contains all the Lists used to Establish the Cross Memory Environment AXL, LXL,TXL The program copies the The Service Block to the STORAGE OBTAIN area. SAC 0 Swicth to Primary ASC mode ALESERV DELETE ATSET AX=AXVALUE,PT=YES,SSAR=YES ETCON TKLIST=TKL,LXLIST=LXL STORAGE RELEASE PR The Disconnect Routine - Removes Access and Removes PT SSAR Authority on behalf of the user address space. The disconnect Routine issues: STORAGE OBTAIN ALESERV ADD SAC 512 Swicth To Acess register Mode The PC Service Block contains all the Lists used to Establish the Cross Memory Environment AXL, LXL,TXLT The program copies the The Service Block to the STORAGE OBTAIN area. SAC 0 Swicth to Primary ASC mode ALESERV DELETE ATSET AX=AXVALUE,PT=NO,SSAR=NO === ETDIS TKLIST=TKL The Third Routine executes as a Stacking Space Switching Service Routine The Service Routine executes the follwoing: OBTAIN STORAGE MVCP 0(R15,R1),0(R14),R0 MVCS 0(R15,R1),0(R14),R0 RELEASE STORAGE PR As I stated earlier I am on a zos 1.7 system. All three modules provide the minimal functionality. Initialy The Connect and Disconnect Routines were loaded by the User calling program and a Modeset Supervisor State
Re: VTOC QUESTION
The answer is - it depends. When an SMS Pool, SMS determines where to place datasets. So you have to make the VTOC large enough to hold any number of datasets. And that number is dependent on the size of the datasets. You need a larger vtoc if you have small files, and a smaller one will work if you only have large files. You have to also consider datasets that can span volumes in an SMS pool that may have a small secondary allocation. So if you can determine that the SMS pool will only get large allocations, you could be okay. But I like to have large vtocs in-case there are unexpected file sizes. That way you do not run into a situation where you have to expand the VTOC or VVDS unexpectedly. I also allocate in Cylinders and not Tracks. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Monday, January 21, 2013 7:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: VTOC QUESTION Good Morning Gentle Readers, What are the advantages of having a large VTOC defined when initializing a volume besides having a large amount of Free DSCBS? Would a smaller VTOC cause response time problems? For example I am adding 3390-9 volumes (10,017 cyls per volume) to a STORAGE GROUP which will only alloc certain dsns which are equal or larger than 1,500 cylinders. From my rough estimation not more than 650 dsns would fit on that volume. Could a vtoc of 29 trks suffice? Thanks for your welcoming comments in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOC QUESTION
W dniu 2013-01-21 14:59, esmie moo pisze: Good Morning Gentle Readers, What are the advantages of having a large VTOC defined when initializing a volume besides having a large amount of Free DSCBS? Would a smaller VTOC cause response time problems? No, larger VTOC would cause response problems, but it was the issue in the old times of non-indexed VTOC. Nowadays large VTOC means only few tracks lost for VTOC. The only advandage of having large VTOC is your good night's sleep - that mean avoided problems due to no room in VTOC. It usually take place according to Murphy's law. For example I am adding 3390-9 volumes (10,017 cyls per volume) to a STORAGE GROUP which will only alloc certain dsns which are equal or larger than 1,500 cylinders. My rule of thumb for 3390-9: VTOC(0,1,149). And I don't care about volume content, because current usage could change in the future. Of course very (very) rare exceptions could apply, i.e. PAGE or SPOOL volumes, or so. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ISFFILTER variable in SDSF REXX
Hi If someone has used the ISFFILTER REXX variable in SDSF ISFLOG command. The question is, if I can filter here the MSGTEXT or not. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
R statistical language.
I wonder if a z/OS port of the following language would be of interest. It might be an interesting way to get some performance information for those of us who cannot afford SAS. http://how-to.linuxcareer.com/introduction-to-gnu-r-on-linux-operating-system But then again, probably not, because it does not have the ability to read SMF data built in to it. And it doesn't run on z/OS. It does run on both Linux and Windows. But, unlike SAS on Linux/Windows, it cannot direct read z/OS data via ftp, as best as I can see. But in the off chance somebody is interested: http://cran.r-project.org/bin/windows/base/ http://www.r-project.org/ home web page -- Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOC QUESTION
On 01/21/2013 07:59 AM, esmie moo wrote: Good Morning Gentle Readers, What are the advantages of having a large VTOC defined when initializing a volume besides having a large amount of Free DSCBS? Would a smaller VTOC cause response time problems? For example I am adding 3390-9 volumes (10,017 cyls per volume) to a STORAGE GROUP which will only alloc certain dsns which are equal or larger than 1,500 cylinders. From my rough estimation not more than 650 dsns would fit on that volume. Could a vtoc of 29 trks suffice? Thanks for your welcoming comments in advance. I have never seen any indication that having excessive free DSCBs has any impact positive or negative on new data set allocation, and if you have a VTOC Index defined (which should always be the case) there should be minimal correlation between VTOC size or used DSCBs, and response time when accessing the VTOC. On the other hand, having no DSCBs left and having unusable free space left on the volume that you would like to use is a serious inconvenience. Throwing extra cylinders at the VTOC at initialization has a minimal cost in DASD space and can avoid future grief. Having to micro-manage VTOC sizes and/or location is not a profitable use of time. I always tried to come up with a worst-case VTOC size requirement for each DASD size and have a single initialization job that could be used in all cases. It makes life so much simpler and you don't have to worry about things later if you decide to use the same volume for smaller data sets, or users circumvent your well-planned SMS strategies by allocating many large datasets with RLSE that end up small. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Passing of Chris Mason reported
Firstly, My condolences to the Mason family. In my opinion it is very bad taste to use a threat announcing the passing of a member of this list as a vehicle to parade ones mastery of several languages and chastise others in there lack of mastery in the use of language(s). None of us follows this list to get language lectures. This is IBM-Main a mainframe related discussion list made up of people from all walks of life and most of them do not have english as their first language. To make that assumption is arrogant and rude. On Fri, Jan 18, 2013 at 6:16 AM, John Gilmore jwgli...@gmail.com wrote: Shmuel's borrowed Churchill quotation would perhaps have been an effective riposte to my post if it too had not been botched: 'errant' should be 'arrant'. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Ian http://www.cicsworld.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: R statistical language.
R has quickly become an essential tool in many research and applied science areas, including insurance and finance. Even the NYT noticed back in 2009: http://www.nytimes.com/2009/01/07/technology/business-computing/07program.html?_r=0 Fortunately, z/OS users can jump right in and use R. Its pretty easy to run R from z/OS using z/OS datasets via a Co:Z Hybrid batch job - //RUNCOZK EXEC PROC=COZPROC, //ARGS='k...@linux1.dovetail.com' //LIFEEXP DD DISP=SHR,DSN=KIRK.LIFEEXP.DATA //STDIN DD * # Run the R statistical system with an inline program # This example is a 2-dimensional multiple regression # The dataset is read from a DD using fromdsn in a R pipe file. # The source of the data is: # www.sci.usq.edu.au/staff/dunn/Datasets/applications/health/lifeexp.html R --no-save EOB mypipe = pipe(fromdsn DD:LIFEEXP, open=r) life = read.table(mypipe, header=TRUE) close(mypipe) multilinearFit = lm(LifeExp~PeoplePerTV+PeoplePerDoctor,data=life) summary(multilinearFit) EOB // A zBX blade is ideal for this kind of hybrid processing. To your other point, SAS is much less expensive if you run in on a distributed platform. In addition, WPS is modestly priced and can run most SAS programs. Here's a white paper with examples of running SAS programs via z/OS hybrid batch jobs, with z/OS dataset input and JES output reports. http://dovetail.com/products/casestudysas.html Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Jan 21, 2013 at 8:43 AM, John McKown john.archie.mck...@gmail.comwrote: I wonder if a z/OS port of the following language would be of interest. It might be an interesting way to get some performance information for those of us who cannot afford SAS. http://how-to.linuxcareer.com/introduction-to-gnu-r-on-linux-operating-system But then again, probably not, because it does not have the ability to read SMF data built in to it. And it doesn't run on z/OS. It does run on both Linux and Windows. But, unlike SAS on Linux/Windows, it cannot direct read z/OS data via ftp, as best as I can see. But in the off chance somebody is interested: http://cran.r-project.org/bin/windows/base/ http://www.r-project.org/ home web page -- Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOC QUESTION
Thanks very much to all those who responded to my post. You have all answered my questions and cleared some nagging doubts. From: Joel C. Ewing jcew...@acm.org To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 21, 2013 9:46:30 AM Subject: Re: VTOC QUESTION On 01/21/2013 07:59 AM, esmie moo wrote: Good Morning Gentle Readers, What are the advantages of having a large VTOC defined when initializing a volume besides having a large amount of Free DSCBS? Would a smaller VTOC cause response time problems? For example I am adding 3390-9 volumes (10,017 cyls per volume) to a STORAGE GROUP which will only alloc certain dsns which are equal or larger than 1,500 cylinders. From my rough estimation not more than 650 dsns would fit on that volume. Could a vtoc of 29 trks suffice? Thanks for your welcoming comments in advance. I have never seen any indication that having excessive free DSCBs has any impact positive or negative on new data set allocation, and if you have a VTOC Index defined (which should always be the case) there should be minimal correlation between VTOC size or used DSCBs, and response time when accessing the VTOC. On the other hand, having no DSCBs left and having unusable free space left on the volume that you would like to use is a serious inconvenience. Throwing extra cylinders at the VTOC at initialization has a minimal cost in DASD space and can avoid future grief. Having to micro-manage VTOC sizes and/or location is not a profitable use of time. I always tried to come up with a worst-case VTOC size requirement for each DASD size and have a single initialization job that could be used in all cases. It makes life so much simpler and you don't have to worry about things later if you decide to use the same volume for smaller data sets, or users circumvent your well-planned SMS strategies by allocating many large datasets with RLSE that end up small. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: R statistical language.
One may try to build that under z/OS USS and it should work (recently somebody discussed here building LiteSQL as pretty simple thing.) I do not think that supporting native z/OS files should be that hard hereafter. Ze'ev Atlas From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 21, 2013 9:43 AM Subject: R statistical language. I wonder if a z/OS port of the following language would be of interest. It might be an interesting way to get some performance information for those of us who cannot afford SAS. http://how-to.linuxcareer.com/introduction-to-gnu-r-on-linux-operating-system But then again, probably not, because it does not have the ability to read SMF data built in to it. And it doesn't run on z/OS. It does run on both Linux and Windows. But, unlike SAS on Linux/Windows, it cannot direct read z/OS data via ftp, as best as I can see. But in the off chance somebody is interested: http://cran.r-project.org/bin/windows/base/ http://www.r-project.org/ home web page -- Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: R statistical language.
On 01/21/2013 08:43 AM, John McKown wrote: I wonder if a z/OS port of the following language would be of interest. It might be an interesting way to get some performance information for those of us who cannot afford SAS. http://how-to.linuxcareer.com/introduction-to-gnu-r-on-linux-operating-system But then again, probably not, because it does not have the ability to read SMF data built in to it. And it doesn't run on z/OS. It does run on both Linux and Windows. But, unlike SAS on Linux/Windows, it cannot direct read z/OS data via ftp, as best as I can see. But in the off chance somebody is interested: http://cran.r-project.org/bin/windows/base/ http://www.r-project.org/ home web page A very quick read suggests R is extendible via packages that can be implemented in other languages (C, C++,...). I guess an interesting question would be whether R provides in some form enough of the features that are in SAS that it would be practical for Barry to port a version of MXG to R so that it could process SMF records under Linux and R. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Stand-alone Dump Revisited
Hi, All, We're looking to clean up our Stand-alone Dump process, and get up to snuff for z/OS 1.13 and beyond. Toward that end we are studying the latest Tech Doc from IBM: http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD103286 But one question (so far) remains: What are the minimum ASIDs we should specify nowadays for a SAD? What should also be in the nice to have list? TIA, -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: R statistical language.
John, I agree , I am typing on my ipad and watching the inauguration. It's hard to get motivated.. Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Jan 21, 2013, at 11:16 AM, John McKown john.archie.mck...@gmail.com wrote: I would image so. The problem, at least for me, is lack of a z/OS C compiler. I guess that I could download some SMF data to my Linux system and write a C routine to read it. I already have one in Java which works fairly well. A big problem for me is lack of energy and interest. On Mon, Jan 21, 2013 at 10:11 AM, Scott Ford scott_j_f...@yahoo.com wrote: I don't know R but it stands to reason that routines can be written to be called to perform formatting of SMF records. Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb -- Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: R statistical language.
Any idea if the GNU C compiler could be ported to the z/OS environment? Scott On 01/21/2013 11:16 AM, John McKown wrote: I would image so. The problem, at least for me, is lack of a z/OS C compiler. I guess that I could download some SMF data to my Linux system and write a C routine to read it. I already have one in Java which works fairly well. A big problem for me is lack of energy and interest. On Mon, Jan 21, 2013 at 10:11 AM, Scott Ford scott_j_f...@yahoo.com wrote: I don't know R but it stands to reason that routines can be written to be called to perform formatting of SMF records. Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: R statistical language.
What do you mean by lack of a z/OS C compiler. Does that mean that your site does not license it? Because I compile C on z/OS with the IBM supplied compiler all the time (both native z.OS and USS, producing good ol' load modules and DLL's at will.) Another possibility is using the GCC (available on, at least, CBTTAPE.ORG) Lack of energy and interest is another issue though! Ze'ev Atlas From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 21, 2013 11:16 AM Subject: Re: R statistical language. I would image so. The problem, at least for me, is lack of a z/OS C compiler. I guess that I could download some SMF data to my Linux system and write a C routine to read it. I already have one in Java which works fairly well. A big problem for me is lack of energy and interest. On Mon, Jan 21, 2013 at 10:11 AM, Scott Ford scott_j_f...@yahoo.com wrote: I don't know R but it stands to reason that routines can be written to be called to perform formatting of SMF records. Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb -- Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: R statistical language.
Available: http://www.cbttape.org/ftp/cbt/CBT853.zip Ze'ev Atlas From: scott svet...@ameritech.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 21, 2013 11:39 AM Subject: Re: R statistical language. Any idea if the GNU C compiler could be ported to the z/OS environment? Scott On 01/21/2013 11:16 AM, John McKown wrote: I would image so. The problem, at least for me, is lack of a z/OS C compiler. I guess that I could download some SMF data to my Linux system and write a C routine to read it. I already have one in Java which works fairly well. A big problem for me is lack of energy and interest. On Mon, Jan 21, 2013 at 10:11 AM, Scott Ford scott_j_f...@yahoo.com wrote: I don't know R but it stands to reason that routines can be written to be called to perform formatting of SMF records. Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: R statistical language.
Correct, no license for the C/C++ compiler. There is no business need. At times, it seems to me that we can barely program in COBOL. There is a port of the GNU C compiler, but it just doesn't seem quite right to me. No, I don't know what that means. On Mon, Jan 21, 2013 at 10:46 AM, Ze'ev Atlas zatl...@yahoo.com wrote: What do you mean by lack of a z/OS C compiler. Does that mean that your site does not license it? Because I compile C on z/OS with the IBM supplied compiler all the time (both native z.OS and USS, producing good ol' load modules and DLL's at will.) Another possibility is using the GCC (available on, at least, CBTTAPE.ORG) Lack of energy and interest is another issue though! Ze'ev Atlas -- Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: R statistical language.
Yeah, it seems that GCC would be a easy fit ... Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Jan 21, 2013, at 11:49 AM, Ze'ev Atlas zatl...@yahoo.com wrote: Available: http://www.cbttape.org/ftp/cbt/CBT853.zip Ze'ev Atlas From: scott svet...@ameritech.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 21, 2013 11:39 AM Subject: Re: R statistical language. Any idea if the GNU C compiler could be ported to the z/OS environment? Scott On 01/21/2013 11:16 AM, John McKown wrote: I would image so. The problem, at least for me, is lack of a z/OS C compiler. I guess that I could download some SMF data to my Linux system and write a C routine to read it. I already have one in Java which works fairly well. A big problem for me is lack of energy and interest. On Mon, Jan 21, 2013 at 10:11 AM, Scott Ford scott_j_f...@yahoo.com wrote: I don't know R but it stands to reason that routines can be written to be called to perform formatting of SMF records. Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Stand-alone Dump Revisited
On Mon, 21 Jan 2013 10:13:54 -0600, John Chase jonboy...@gmail.com wrote:
Hi, All,
We're looking to clean up our Stand-alone Dump process, and get up to
snuff for z/OS 1.13 and beyond. Toward that end we are studying the latest
Tech Doc from IBM:
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD103286
But one question (so far) remains: What are the minimum ASIDs we should
specify nowadays for a SAD? What should also be in the nice to have list?
I can tell you what I have. There was a thread about this sometime in the
past year (I think) - search the archives. I think Barbara may have
posted something different than I use, but this is what I currently
have for z/OS 1.13:
DUMP=('SP(ALL) IN ASID(1) ALSO DATASPACES OF ASID(1,'JES-
XCF','APPC','SMSVSAM','CONSOLE','SMSPDSE','SMSPDSE1','OM-
VS') ALSO PAGETABLES OF DATASPACES -
ALSO SP(ALL) IN ASID('JES2')-
'), -
Regards,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOC QUESTION
On Jan 21, 2013, at 8:46 AM, Joel C. Ewing jcew...@acm.org wrote: I have never seen any indication that having excessive free DSCBs has any impact positive or negative on new data set allocation, and if you have a VTOC Index defined (which should always be the case) there should be minimal correlation between VTOC size or used DSCBs, and response time when accessing the VTOC. On the other hand, having no DSCBs left and having unusable free space left on the volume that you would like to use is a serious inconvenience. Throwing extra cylinders at the VTOC at initialization has a minimal cost in DASD space and can avoid future grief. Having to micro-manage VTOC sizes and/or location is not a profitable use of time. The only downside of a too large VTOC is that the extra space is not available for data sets. Since I've set up the SMS pools by size, I can adjust the VTOC size to match each pool. I have an initialization job for each pool. It's not a lot more difficult than one size fits all. I always tried to come up with a worst-case VTOC size requirement for each DASD size and have a single initialization job that could be used in all cases. It makes life so much simpler and you don't have to worry about things later if you decide to use the same volume for smaller data sets, or users circumvent your well-planned SMS strategies by allocating many large datasets with RLSE that end up small. I have a daily job that finds these data sets and uses FDRDSF to move them to the appropriate pool. -- Curtis Pew (c@its.utexas.edu) ITS Systems Core The University of Texas at Austin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOC QUESTION
The only downside of a too large VTOC is that the extra space is not available for data sets. How much space is 'lost' to make a difference? Especially, on a -9 or larger? Since I've set up the SMS pools by size, I can adjust the VTOC size to match each pool. I have an initialization job for each pool. It's not a lot more difficult than one size fits all. But, is it truly worth the effort? I've always had a one size fits all, ever since 3350's. I just adjust as the technology, or the guidelines change. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Searching for storage (DASD) alternatives
In of3704cbe6.221b8755-on48257afa.002a9c2b-48257afa.002b9...@sg.ibm.com, on 01/21/2013 at 03:55 PM, Timothy Sipples sipp...@sg.ibm.com said: I don't follow the logic. The logic is that the incremental cost was less for VSE because part of the work had been done decades earlier. The ease or difficulty of doing something is not measured when something isn't done. I'm referring to the incremental cost, not the total cost. All we can logically conclude was that it was easy enough for IBM to add that support to DOS when it did. No, we can logically conclude that the cost of adding SCSI support to the later code base did not include the work that had already been done for other reasons. It might indeed have been more difficult with MVS, But even if it would have been easier for MVS, what is relevant is that IBM didn't do so, so to add FCP SCSI support now IBM would have to either add FBA support or limit SCP SCSI to, e.g., Unix file systems. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
TSO ALLOCATE REUSE ENQ?
From the description of the ALLOCATE command in the TSO/E Commands manal: REUSE specifies the file name being allocated is to be freed and reallocated if it is currently in use. When you allocate a data set with file name or ddname, give it a disposition of SHR or OLD. You cannot use the REUSE operand to reallocate a file from a disposition of OLD to a disposition of SHR. However, you can first free the file with a disposition of OLD, then reallocate it with a disposition of SHR. How can restriction be? It seems that if the file is first FREEd, the ENQ is removed and reallocating SHR should just work. What's going on here that they're not telling me. It seems that the first paragraph is somehow incorrect and a RCF is in order. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOC QUESTION
Just to satisfy my own curiosity, I do you plan to fit 650 datasets, each a minimum of 1,500 cylinders, on a volume with only 10,000 cylinders? How will you even get more than 6? A 3390 will fit 53 DSCBs per track. 29 tracks will hold 1537 DSCBs, slightly more than twice what you expect. ISPF 3.4 with the V option will tell you how full the VTOC is. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of esmie moo :: Sent: Monday, January 21, 2013 6:00 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: VTOC QUESTION :: :: Good Morning Gentle Readers, :: :: What are the advantages of having a large VTOC defined when initializing :: a volume besides having a large amount of Free DSCBS? Would a smaller :: VTOC cause response time problems? :: :: For example I am adding 3390-9 volumes (10,017 cyls per volume) to a :: STORAGE GROUP which will only alloc certain dsns which are equal or :: larger than 1,500 cylinders. :: :: From my rough estimation not more than 650 dsns would fit on that :: volume. Could a vtoc of 29 trks suffice? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Searching for storage (DASD) alternatives
I could go for your last: limit SCP SCSI. But I would basically extend it to anything which is FBA compatible. That is basically all of VSAM. Which include z/OS UNIX filesystems by default because z/OS UNIX filesystems are implemented via VSAM LINEAR data sets. And, if that happened, I would really like it if IBM z/OS development would do what VSE did long ago: make VSAM ESDS accessible via a QSAM interface. They did that for ISAM programs long ago for VSAM KSDS data sets. On Mon, Jan 21, 2013 at 11:54 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In snip But even if it would have been easier for MVS, what is relevant is that IBM didn't do so, so to add FCP SCSI support now IBM would have to either add FBA support or limit SCP SCSI to, e.g., Unix file systems. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Passing of Chris Mason reported
On Mon, Jan 21, 2013 at 10:02 AM, Ian pcs...@gmail.com wrote: Firstly, My condolences to the Mason family. In my opinion it is very bad taste to use a threat announcing the passing of a member of this list as a vehicle to parade ones mastery of several languages and chastise others in there lack of mastery in the use of language(s). None of us follows this list to get language lectures. This is IBM-Main a mainframe related discussion list made up of people from all walks of life and most of them do not have english as their first language. To make that assumption is arrogant and rude. You are, of course, correct. You are, of course, also bailing the ocean -- the pedants and troublemakers on this list are beyond help.They often seem to want to provoke others, and when challenged directly, step away. They're just trolls. Some of them also whine occasionally about being unable to find work. There couldn't possibly be a connection between their behavior and that problem, of course... -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOC QUESTION
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Monday, January 21, 2013 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOC QUESTION The only downside of a too large VTOC is that the extra space is not available for data sets. How much space is 'lost' to make a difference? Especially, on a -9 or larger? The answer is either 42 or else it depends. If you want to make your VTOC large enough for the worst possible case, then you need to do some research on your own data center and then do some calculations. E.g., if your data center has software in place (SMS exits, e.g.) to limit allocation of new data sets on volser XXX to files of at least YYY megabytes, then you can calculate approximately how many files of that size will fit on volser XXX based on the known size (known to you) of that volume. Let's say the answer is 999. Next you have to calculate how big the VTOC will have to be to hold at least 999 Format 1 and/or Format 8 DSCBs. A 3390 track can hold 50 DSCBS, either exactly or approximately, so that means the VTOC must have 999 divided by 50 tracks, or 20 tracks. You should certainly allow some extra space in the VTOC, so you might want to round those 20 tracks up to 2 whole cylinders. But Format 1/8 DSCBs are not the only kind of DSCBs that might need to be stored in your VTOC. As files grow, some Format 3 and/or 9 DSCBs may be needed. As another poster said, sometimes a user allocates a new file with SPACE=(huge,RLSE). This file might be allocated on XXX but when it is fully created the RLSE function reduces it down to only one track. Even a final size of zero tracks is theoretically possible. If this happens a lot, then many of your 999 DSCBs will be used to hold a Format 1/8 DSCB for a data set that is YYY megabytes. Then someday a user will not be able to allocate a new file of size YYY megabytes because there are no Format 0 DSCBs left in XXX's VTOC but yet there are a gazillion available cylinders of space on XXX. If your data center has some automated process to look for datasets on XXX that are smaller than YYY megabytes and move them elsewhere, then whether or not your users may suffer a new allocation failure will depend on how often your users do a (huge,RLSE) and how often your automated removal process occurs. To be absolutely safe, the worst of all possible worst cases is that every track on a DASD volume could theoretically become a single-track data set. So compute how many tracks are on your volser XXX, then divide that number by 50 and you will know how many tracks in size your VTOC must be. E.g., if you have a 3390-9 with 9*1113 cylinders, then you have 150,255 tracks on the volume. One out of every 50 tracks will be required for the VTOC, so you really have 150,255 times 49/50, or 147,250 tracks available to hold one-track data sets and that VTOC will have to have 147,250 DSCBs divided by 50 DSCBs per track in it, which is 2,945 tracks or 196 cylinders. In other words, only 98% of your huge volume is available to hold user data, and the other 2% must be devoted to holding metadata for the utmost extremely worst case. At the other extreme, the best of all possible best cases is that your mod 9 holds only one truly huge data set. You can then have a one-track VTOC and a one-track VTOC index data set (but with only one data set on the volume, why do you really need a VTOC index there?), plus one more track for the volume label, so three tracks total would hold all the necessary metadata, leaving 150,255 minus 3 equals 150,252 tracks to hold your single humongous file of about 8.4 gigabytes (if you manage to cram 56K bytes on each track, which is possible but not easy to do). It's much more likely that you can only cram at most 52K bytes on each track. Bottom line -- a mod 9 VTOC needs to be somewhere between 1 track and 196 cylinders. It depends. Or 42, which is another good answer based on other criteria. But is it truly worth the effort? It depends. Whenever a new file allocation fails, some DASD space guru will need to be involved in determining why the failure occurred and what to do to get the file allocated somewhere. That guru may be the original user or may be you. But somebody has to do it, and probably most users don't have the foggiest. How often do your users have a new allocation fail for the reason that the VTOC is too small? Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 0D7 with ATSET
IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 01/21/2013 08:53:35 AM: From: esst...@juno.com esst...@juno.com To: IBM-MAIN@listserv.ua.edu, Date: 01/21/2013 02:54 PM Subject: Re: 0D7 with ATSET Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu Jim Mulder wrote Your ATSET does a stacking PC-cp. The ATSET service routine removes secondary authority for your server's AX to your User space. ATSET tries to return via PR, but since you invoked ATSET in cross memory mode, this is PR-ss, and secondary authority checking is done. The resulting SASN would be your User spaces's ASN, and the ATSET has just removed that authority. So the PR-ss results in a program check code x'025', which z/OS turns into a 0D7-025 abend. Does this mean a Space Switching PC cannot be used to remove the users access ? That is correct. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOC QUESTION
The first 3 extents fit in the Format-1 DSCB. The next 13 fit in the Format-3 DSCB. What is the third DSCB you think is needed? You can still fit only 6 1500 cylinder datasets on a 10,000 cylinder device. Even if a third DSCB is needed, you still need only 18 DSCBs which will fit is a single track. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Mike Schwab :: Sent: Monday, January 21, 2013 10:16 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: VTOC QUESTION :: :: 3 DSCBs for 16 extents, so keeping extents down will be needed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO ALLOCATE REUSE ENQ?
Did you try it and see it works or if the limitation in the manual is correct? :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Paul Gilmartin :: Sent: Monday, January 21, 2013 9:58 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: TSO ALLOCATE REUSE ENQ? :: :: From the description of the ALLOCATE command in the TSO/E :: Commands manal: :: :: REUSE :: specifies the file name being allocated is to be freed and :: reallocated :: if it is currently in use. :: :: When you allocate a data set with file name or ddname, give it a :: disposition :: of SHR or OLD. You cannot use the REUSE operand to reallocate a file :: from :: a disposition of OLD to a disposition of SHR. However, you can first :: free the :: file with a disposition of OLD, then reallocate it with a :: disposition of SHR. :: :: How can restriction be? It seems that if the file is first FREEd, the :: ENQ is :: removed and reallocating SHR should just work. What's going on here :: that they're not telling me. :: :: It seems that the first paragraph is somehow incorrect and a RCF is in :: order. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO ALLOCATE REUSE ENQ?
On Mon, 21 Jan 2013 14:16:23 -0800, retired mainframer wrote: Did you try it and see it works or if the limitation in the manual is correct? Good idea, of course. I've tried it now. That much is true. :: -Original Message- :: Behalf Of Paul Gilmartin :: Sent: Monday, January 21, 2013 9:58 AM :: :: From the description of the ALLOCATE command in the TSO/E :: Commands manal: :: :: REUSE :: specifies the file name being allocated is to be freed and reallocated :: if it is currently in use. :: :: When you allocate a data set with file name or ddname, give it a disposition :: of SHR or OLD. You cannot use the REUSE operand to reallocate a file from :: a disposition of OLD to a disposition of SHR. However, you can first free the :: file with a disposition of OLD, then reallocate it with a disposition of SHR. :: :: How can [that] restriction be? It seems that if the file is first FREEd, the ENQ is :: removed and reallocating SHR should just work. What's going on here :: that they're not telling me. :: :: It seems that the first paragraph is somehow incorrect and a RCF is in :: order. Lots of other stuff I can put in my putative RCF: The suggestion to free and allocate with SHR should be accompanied by a caution that this may allow another job, waiting on an ENQ to gain control and the allocate may fail with DATA SET IN USE. The instruction to use SHR or OLD implies that NEW and MOD are mutually exclusive with REUSE. But I'm sure I've used NEW REUSE. Is there really such a restriction? The restriction states that a prior disposition of OLD may not be converted to SHR. But it says nothing about NEW or MOD. May I safely assume, then, that a prior disposition of NEW or MOD will sucessfully be converted to SHR? If the prior disposition is MOD and I specify SHR REUSE, does the disposition become SHR, does it remain MOD, or is it magically converted to OLD? Does the restriction apply only if tne new data set name is the same as the data set name in the prior allocation, or regardless if the names differ? I think I already know the answers to most of these questions or can discover them by experiment (which is a poor substitute for documentation), but the Manual ought also to serve the novice programmer with little experience. All this presumes much familiarity with z/OS concepts and facilities with nary a suggestion how this information may be obtained. I bet Steve C. has some ideas to that end. OK. The TSO/E Command Reference has a Where to Find More Information, which menions TSO/E User Guide and Information Roadmap (which may mention Using Data Sets). So much background for such an apparently simple command. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO ALLOCATE REUSE ENQ?
On 1/21/2013 3:08 PM, Paul Gilmartin wrote: So much background for such an apparently simple command. MVS allocation is not a simple topic. Never has been. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOC QUESTION
In 1358776795.52550.yahoomail...@web165006.mail.bf1.yahoo.com, on 01/21/2013 at 05:59 AM, esmie moo esmie_...@yahoo.ca said: What are the advantages of having a large VTOC defined when initializing a volume besides having a large amount of Free DSCBS? None. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: R statistical language.
On 21/01/2013 11:35 PM, Ze'ev Atlas wrote: One may try to build that under z/OS USS and it should work (recently somebody discussed here building LiteSQL as pretty simple thing.) I do not think that supporting native z/OS files should be that hard hereafter. To port R to z/OS Unix you will need a Fortran compiler. Although the base language is written in C lots of R modules are written in Fortran. Ze'ev Atlas From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 21, 2013 9:43 AM Subject: R statistical language. I wonder if a z/OS port of the following language would be of interest. It might be an interesting way to get some performance information for those of us who cannot afford SAS. http://how-to.linuxcareer.com/introduction-to-gnu-r-on-linux-operating-system But then again, probably not, because it does not have the ability to read SMF data built in to it. And it doesn't run on z/OS. It does run on both Linux and Windows. But, unlike SAS on Linux/Windows, it cannot direct read z/OS data via ftp, as best as I can see. But in the off chance somebody is interested: http://cran.r-project.org/bin/windows/base/ http://www.r-project.org/ home web page -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: R statistical language.
Well I was not aware about that fact, so I downloaded the source code and indeed it uses Fortran - interesting, I may spend some time with that stuff. However, both IBM and GNU provide pretty advanced Fortran compilers, but it becomes more and more hairy to deal with it. Yet, if there is a demand, somebody would probably do that. And interfacing native z/OS files and SMF in particular should not be that hard. Ze'ev Atlas From: David Crayford dcrayf...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 21, 2013 9:26 PM Subject: Re: R statistical language. On 21/01/2013 11:35 PM, Ze'ev Atlas wrote: One may try to build that under z/OS USS and it should work (recently somebody discussed here building LiteSQL as pretty simple thing.) I do not think that supporting native z/OS files should be that hard hereafter. To port R to z/OS Unix you will need a Fortran compiler. Although the base language is written in C lots of R modules are written in Fortran. Ze'ev Atlas From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 21, 2013 9:43 AM Subject: R statistical language. I wonder if a z/OS port of the following language would be of interest. It might be an interesting way to get some performance information for those of us who cannot afford SAS. http://how-to.linuxcareer.com/introduction-to-gnu-r-on-linux-operating-system But then again, probably not, because it does not have the ability to read SMF data built in to it. And it doesn't run on z/OS. It does run on both Linux and Windows. But, unlike SAS on Linux/Windows, it cannot direct read z/OS data via ftp, as best as I can see. But in the off chance somebody is interested: http://cran.r-project.org/bin/windows/base/ http://www.r-project.org/ home web page -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: R statistical language.
Ze'ev... Do a listidr on one of the IBM compiler modules in question it should be easy to determine. Offhand I would guess PLX (certainly not C) . Ed On Jan 21, 2013, at 9:41 PM, Ze'ev Atlas wrote: One more point There is nothing really new anymore. In the olden days one would create a compiler for a new language X and have it written in X, but those days are no more! It seems that all new compilers are written in C - or in Fortran, nowadays. I wonder what are COBOL and PL/I compilers written in? Is that still PLX or did IBM move to C as well. Ze'ev Atlas From: David Crayford dcrayf...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 21, 2013 9:26 PM Subject: Re: R statistical language. On 21/01/2013 11:35 PM, Ze'ev Atlas wrote: One may try to build that under z/OS USS and it should work (recently somebody discussed here building LiteSQL as pretty simple thing.) I do not think that supporting native z/OS files should be that hard hereafter. To port R to z/OS Unix you will need a Fortran compiler. Although the base language is written in C lots of R modules are written in Fortran. Ze'ev Atlas From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 21, 2013 9:43 AM Subject: R statistical language. I wonder if a z/OS port of the following language would be of interest. It might be an interesting way to get some performance information for those of us who cannot afford SAS. http://how-to.linuxcareer.com/introduction-to-gnu-r-on-linux- operating-system But then again, probably not, because it does not have the ability to read SMF data built in to it. And it doesn't run on z/OS. It does run on both Linux and Windows. But, unlike SAS on Linux/Windows, it cannot direct read z/OS data via ftp, as best as I can see. But in the off chance somebody is interested: http://cran.r-project.org/bin/windows/base/ http://www.r-project.org/ home web page -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
slightly O/T but interesting
The top 25 worst passwords, in order (and their current rankings compared with the previous year's rankings), are below. 1. password (unchanged) 2. 123456 (unchanged) 3. 12345678 (unchanged) 4. abc123 (up 1) 5. qwerty (down 1) 6. monkey (unchanged) 7. letmein (up 1) 8. dragon (up 2) 9. 11 (up 3) 10. baseball (up 1) 11. iloveyou (up 2) 12. trustno1 (down 3) 13. 1234567 (down 6) 14. sunshine (up 1) 15. master (down 1) 16. 123123 (up 4) 17. welcome (new) 18. shadow (up 1) 19. ashley (down 3) 20. football (up 5) 21. jesus (new) 22. michael (up 2) 23. ninja (new) 24. mustang (new) 25. password1 (new) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Stand-alone Dump Revisited
I saw Barbara's note about including the dataspaces belonging to OMVS, but
haven't seen a complete generation deck (or significant excerpt) from her
yet.
You've asked for it:
AMDSADMP IPL=D3390,VOLSER=xx, +
REUSEDS=ALWAYS,IPLEXIST=YES,+
DUMP=('DSP OF ASID(ALL) ALSO PAGETABLES OF DATASPACES +
ALSO SP(ALL) IN ASID(ALL) +
ALSO HIGH VIRTUAL IN ASID(ALL)'), +
MINASID=ALL,+
DDSPROMPT=NO, +
OUTPUT=(D,MVSR.SADMP), +
CONSOLE=SYSC
END
We had been running with this and even taking a few sadumps. A heavily
(over-)used 8GB lpar took about 10 minutes to 3 volsers via autoipl/sadump. The
beauty of the above is that it works on autoipl with no operator intervention
required (you know, those 30 minutes operators take to find the correct
document, read through it and do what it says?). The MVSR.SADMP is a historical
relict and had caused me some grief on an sadump restart. Check the archives,
at that time we discussed why it would be better to use sys1.sadmp.
And I see that we were better than system test - we did specify HIGH VIRTUAL
:-) I just wanted to avoid software supports' constant 'The data are not in the
dump' arguments by specifying everything and then proving to them that they
have no clue where to look. So I made it easy for me and just specified ALL for
just about everything.
Barbara
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF RC20 on SELECT PGM(xxx) PARM(yyy) clues needed
I would suggest to use the ISPF Dialog test feature with the Functions/Variable - ALL and then log each entry and see where and why issue is coming going in the ISPF Log.. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sharing TS7700 across sms plex
SC35-0427-09 DFSMS OAM Planning, Installation, and Storage Administration Guide for Tape Libraries ..Sorry for late reply -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
