Re: Cbttape - dataset being used
On 10/15/2020 10:19 PM, David Crayford wrote: There's no need to install TASID. The ISPF ISRDDN utility has an ENQ dialog and is shipped as part of ISPF. From any command line enter DDLIST;ENQ. The major advantage to TASID is that it has a switch which will give you the GRS Star information so you can see the ENQ's for all the systems in the SYSPLEX. That feature, unfortunately, was not included in ISRDDN. ISRDDN will only show you local ENQ's. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Batch SFTP without client keys or USS files?
On Thu, 15 Oct 2020 19:36:33 -0500, Wendell Lovewell wrote: > >... modifying USS files like even ~/.ssh/anything is probably also off >limits. > Why? But I'd expect you'd need to install the client's public key in the server's authorized_keys, which might be a problem. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cbttape - dataset being used
There's no need to install TASID. The ISPF ISRDDN utility has an ENQ dialog and is shipped as part of ISPF. From any command line enter DDLIST;ENQ. On 2020-10-14 8:55 PM, Roberto Halais wrote: Joe: Thank you for the info. Just one detail. I checked and it's FILE980 in CBT for the TASID fix. On Wed, Oct 14, 2020 at 8:04 AM Joe Monk wrote: You can acquire TASID here: https://www.ibm.com/support/pages/node/572789 There is a ZAP for it in CBT 981 to fix the initiator display on z/os 2.2 and 2.3 Joe On Wed, Oct 14, 2020 at 6:22 AM Roberto Halais wrote: There is a utility called TASID which can give you what you want. I don't know if it's in CBT. We use it. Select one of the following options: Version 5.21 1 - Address space list5 - Miscellaneous displays 2 - System ENQ contention 6 - Current dataset allocations 3 - Total system ENQ status 7 - Storage View Facility 4 - Initiator Status List 8 - Snapshot On Wed, Oct 14, 2020 at 2:29 AM Jake Anderson wrote: Hello Are there any freeware utility in CBTTAPE to check if a specific dataset is being used in parmlibs or proclib or by any batch ? Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Politics: Poli (many) - tics (blood sucking parasites) -- 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: Batch SFTP without client keys or USS files?
Classification: HCL Internal
Yes it is . I do this many times daily.
There are 2 stages to the authentication. Server and User.
For Server Authentication, all that is needed is the public key of the foreign
host in the /etc/ssh./known_hosts
For the sake of discussion, I am going to assusme this is MF--.foreign host.
You need to install the foreign host public key (for whatever user on the
foreign host) in /&uid/.ssh/authorized_keys.
The job(s) will run with a ESM id of &UID.
CoZ makes things much easier than the zOS version of OpenSSH, but is not
required. The IBM code can handle everything just fine.
For more info see: http://www.dovetail.com/webinars.html
Towards the bottom of the page you will see: " IBM Ported Tools for z/OS:
OpenSSH - Key Authentication"
Although Dovetail produced the content, it is non-CoZ dependent.
Disclaimer. I have no affiliation with Dovetail except as a user of their fine
products.
HTH,
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Wendell Lovewell
Sent: Thursday, October 15, 2020 7:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Batch SFTP without client keys or USS files?
[CAUTION: This Email is from outside the Organization. Unless you trust the
sender, Don’t click links or open attachments as it may be a Phishing email,
which can steal your Information and compromise your Computer.]
Is it possible to code a proc that would invoke SFTP to transfer a file to or
from a non-z/OS ftp server using only that server's public key and a
userid/password combination like you would use for FTP or FTPS?
I need to distribute this outside our company, so using CO:Z isn't an option.
Adding keys to the server for the clients is not either. And modifying USS
files like /etc/ssh/config or even ~/.ssh/anything is probably also off limits.
I might be able to get away with stashing something in /tmp, but even that
might be a problem. I can (since I have to) assume z/OS 2.2 or later for
OpenSSH availability.
I was able to do this for FTPS by distributing the FTP server's public key as a
.PEM file & installing it into RACF, then adding it to a keyring. But so far
with SFTP, I'm stumped. Has anyone tried this?
TIA,
Wendell
fwiw, here is the FTPS proc:
//*---
//* TERSE a file & FTP it
//*---
//FTPSTRS PROC ZOSFILE=,
// FTPFILE=,
// OUTCLS=*,
// TMPHLQ=&SYSUID,
// TRSDISP=(NEW,PASS),
// KEYOWNR=TCPIP,
// KEYRING=FTPS.KEYRING
//*
//EXP EXPORT SYMLIST=*
// SETFTPFID=&FTPFILE
// SETFTPOWN=&KEYOWNR
// SETFTPKEY=&KEYRING
//*
//*---
//TERSEEXEC PGM=TRSMAIN,PARM=PACK
//SYSPRINT DD SYSOUT=&OUTCLS
//INFILE DD DISP=SHR,DSN=&ZOSFILE
//OUTFILEDD DSN=&TMPHLQ..TEMP.TRS,
// DISP=(&TRSDISP.),
// RECFM=FB,BLKSIZE=0,LRECL=1024,
// LIKE=&ZOSFILE
//*---
//FTPS EXEC PGM=FTP,REGION=4M,COND=(0,LT),
// PARM=('ENVAR("_CEE_ENVFILE_S=DD:STDENV")/ftp.server.com 21 -e')
//STDENV DD *
GSK_PROTOCOL_TLSV1_2=ON
//SYSFTPD DD *,SYMBOLS=(JCLONLY)
CLIENTERRCODES EXTENDED
EPSV4TRUE
EXTENSIONS AUTH_TLS
FWFRIENDLY TRUE
KEYRING&FTPOWN/&FTPRING
PASSIVEIGNOREADDR TRUE
SECUREIMPLICITZOS FALSE
SECURE_FTP REQUIRED
SECURE_MECHANISM TLS
SECURE_DATACONNPRIVATE
SECURE_CTRLCONNPRIVATE
SECURE_HOSTNAME REQUIRED
TLSMECHANISM FTP
TLSRFCLEVEL RFC4217
//* TRACE
//TRSFILE DD DISP=SHR,DSN=*.TERSE.OUTFILE
//OUTPUT DD SYSOUT=&OUTCLS
//INPUT DD *,SYMBOLS=(JCLONLY)
ftpuser
ftppwd
sendsite
cd /somedir
BINARY
PUT //DD:TRSFILE &FTPFID
QUIT
//*
// PEND
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only. E-mail transmission is not guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or may contain viruses in transmission.
The e mail and its contents (with or without referred errors) shall therefore
not attach any liability on the originator or HCL or its affiliates. Views or
opinions, if any, presented in this email are solely those of the author and
may not necessarily reflect the views or opinions of HCL or its affiliates. Any
form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior wr
Batch SFTP without client keys or USS files?
Is it possible to code a proc that would invoke SFTP to transfer a file to or
from a non-z/OS ftp server using only that server's public key and a
userid/password combination like you would use for FTP or FTPS?
I need to distribute this outside our company, so using CO:Z isn't an option.
Adding keys to the server for the clients is not either. And modifying USS
files like /etc/ssh/config or even ~/.ssh/anything is probably also off limits.
I might be able to get away with stashing something in /tmp, but even that
might be a problem. I can (since I have to) assume z/OS 2.2 or later for
OpenSSH availability.
I was able to do this for FTPS by distributing the FTP server's public key as a
.PEM file & installing it into RACF, then adding it to a keyring. But so far
with SFTP, I'm stumped. Has anyone tried this?
TIA,
Wendell
fwiw, here is the FTPS proc:
//*---
//* TERSE a file & FTP it
//*---
//FTPSTRS PROC ZOSFILE=,
// FTPFILE=,
// OUTCLS=*,
// TMPHLQ=&SYSUID,
// TRSDISP=(NEW,PASS),
// KEYOWNR=TCPIP,
// KEYRING=FTPS.KEYRING
//*
//EXP EXPORT SYMLIST=*
// SETFTPFID=&FTPFILE
// SETFTPOWN=&KEYOWNR
// SETFTPKEY=&KEYRING
//*
//*---
//TERSEEXEC PGM=TRSMAIN,PARM=PACK
//SYSPRINT DD SYSOUT=&OUTCLS
//INFILE DD DISP=SHR,DSN=&ZOSFILE
//OUTFILEDD DSN=&TMPHLQ..TEMP.TRS,
// DISP=(&TRSDISP.),
// RECFM=FB,BLKSIZE=0,LRECL=1024,
// LIKE=&ZOSFILE
//*---
//FTPS EXEC PGM=FTP,REGION=4M,COND=(0,LT),
// PARM=('ENVAR("_CEE_ENVFILE_S=DD:STDENV")/ftp.server.com 21 -e')
//STDENV DD *
GSK_PROTOCOL_TLSV1_2=ON
//SYSFTPD DD *,SYMBOLS=(JCLONLY)
CLIENTERRCODES EXTENDED
EPSV4TRUE
EXTENSIONS AUTH_TLS
FWFRIENDLY TRUE
KEYRING&FTPOWN/&FTPRING
PASSIVEIGNOREADDR TRUE
SECUREIMPLICITZOS FALSE
SECURE_FTP REQUIRED
SECURE_MECHANISM TLS
SECURE_DATACONNPRIVATE
SECURE_CTRLCONNPRIVATE
SECURE_HOSTNAME REQUIRED
TLSMECHANISM FTP
TLSRFCLEVEL RFC4217
//* TRACE
//TRSFILE DD DISP=SHR,DSN=*.TERSE.OUTFILE
//OUTPUT DD SYSOUT=&OUTCLS
//INPUT DD *,SYMBOLS=(JCLONLY)
ftpuser
ftppwd
sendsite
cd /somedir
BINARY
PUT //DD:TRSFILE &FTPFID
QUIT
//*
// PEND
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cbttape - dataset being used
Also there is the ISPF built in ISRDDN. ENQ command on the command line. On Thu, 15 Oct 2020 at 05:32, Brian Westerman wrote: > Also there is MXI (option ENQ). Also on the CBT > > -- > 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: INTRDR and submitted JobID
On Thu, 15 Oct 2020 11:17:45 -0500, Salva Carrasco wrote: >Not yet: DML was expanded to 8 char. > More context, please. Which statement in which earlier ply are you discussing? And what's a "DML"? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTRDR and submitted JobID
Not yet: DML was expanded to 8 char. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: ISPF dsn sort
Classification: Limited I concur; deselecting 'Display Total Tracks' causes the progress bar to appear on a SORT command - I always have that selected, along with 'Show Catalog Name'. Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: 15 October 2020 15:01 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: ISPF dsn sort -- This email has reached the Bank via an external source -- That's not what is happening. A different poster nailed it earlier. If the "Display Total Tracks" is selected on the dataset list utility screen, the first time you hit PF10/11 to go right or left, ISPF needs to read the entire list in order to populate the "total tracks" line. Thus you get the progress bar. If you don't have that selected, ISPF only works with the screen's worth of data so no progress bar until you do a sort. Once the sort is requested, ISPF needs to read the entire list to be able to do the sort correctly. Once ISPF has all the information it needs, you can resort the data any way you want and it won't need to reread it. At least that's what I've seen with my testing of it. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bob Bridges Sent: Thursday, October 15, 2020 6:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: ISPF dsn sort I've never noticed the behavior, but now that the OP has pointed it out, the reading-the-list-again explanation doesn't satisfy me. If there's a delay and a progress bar when reading the list to do the sort, why is there no similar delay when scrolling right to see the data which (according to this explanation) has not yet been collected? I'm not buying it. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Our world is not divided by race, color, gender, or religion. Our world is divided into wise people and fools. And fools divide themselves by race, color, gender, or religion. -Mohamad Safa */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Tuesday, October 13, 2020 13:12 This is one of those IIRC posts. I think this behavior goes back decades. The reason is as Kolusu states. Moreover--IIRC--the very appearance of the 'progress bar' was in response to what could be a long delay. Delay to the point that the user might suspect that the process was hung outright. I remember when the bar was introduced with that very explanation. Everything in those distant days was slower than today. As for the difference in processing, I could imagine an RFE asking for a 'quick sort' based only on the data previously collected and displayed. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sri h Kolusu Sent: Tuesday, October 13, 2020 9:47 AM 3.4 listing shows the list of datasets sorted on the Dataset name by default. Now when you issue SORT DSORG command , ISPF needs to read in the list once again and make DSORG as the primary key and then present you the list sorted on that order. You will -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: Tuesday, October 13, 2020 11:18 This is something that has puzzled me for years. I can use ISPF 3.4 to display a set of data sets. If I scroll right then I am shown the space usage figures. Scroll right again and I am shown the DSORG, RECFM, Lrecl and Blksize. If I now enter SORT DSORG I am presented with a progress bar and I am informed that information is being collected to perform the sort. Given that the DSORG was already displayed, why does ISPF go and collect the same information again? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham S
Re: [External] Re: ISPF dsn sort
That's not what is happening. A different poster nailed it earlier. If the "Display Total Tracks" is selected on the dataset list utility screen, the first time you hit PF10/11 to go right or left, ISPF needs to read the entire list in order to populate the "total tracks" line. Thus you get the progress bar. If you don't have that selected, ISPF only works with the screen's worth of data so no progress bar until you do a sort. Once the sort is requested, ISPF needs to read the entire list to be able to do the sort correctly. Once ISPF has all the information it needs, you can resort the data any way you want and it won't need to reread it. At least that's what I've seen with my testing of it. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bob Bridges Sent: Thursday, October 15, 2020 6:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: ISPF dsn sort I've never noticed the behavior, but now that the OP has pointed it out, the reading-the-list-again explanation doesn't satisfy me. If there's a delay and a progress bar when reading the list to do the sort, why is there no similar delay when scrolling right to see the data which (according to this explanation) has not yet been collected? I'm not buying it. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Our world is not divided by race, color, gender, or religion. Our world is divided into wise people and fools. And fools divide themselves by race, color, gender, or religion. -Mohamad Safa */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Tuesday, October 13, 2020 13:12 This is one of those IIRC posts. I think this behavior goes back decades. The reason is as Kolusu states. Moreover--IIRC--the very appearance of the 'progress bar' was in response to what could be a long delay. Delay to the point that the user might suspect that the process was hung outright. I remember when the bar was introduced with that very explanation. Everything in those distant days was slower than today. As for the difference in processing, I could imagine an RFE asking for a 'quick sort' based only on the data previously collected and displayed. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sri h Kolusu Sent: Tuesday, October 13, 2020 9:47 AM 3.4 listing shows the list of datasets sorted on the Dataset name by default. Now when you issue SORT DSORG command , ISPF needs to read in the list once again and make DSORG as the primary key and then present you the list sorted on that order. You will -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: Tuesday, October 13, 2020 11:18 This is something that has puzzled me for years. I can use ISPF 3.4 to display a set of data sets. If I scroll right then I am shown the space usage figures. Scroll right again and I am shown the DSORG, RECFM, Lrecl and Blksize. If I now enter SORT DSORG I am presented with a progress bar and I am informed that information is being collected to perform the sort. Given that the DSORG was already displayed, why does ISPF go and collect the same information again? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF dsn sort
On Thu, 15 Oct 2020, at 12:02, Bob Bridges wrote: > I've never noticed the behavior, but now that the OP has pointed it > out, the reading-the-list-again explanation doesn't satisfy me. If > there's a delay and a progress bar when reading the list to do the > sort, why is there no similar delay when scrolling right to see the > data which (according to this explanation) has not yet been collected? Maybe because the scroll-right only has to populate one screenful's set of values, but the sort has to populate the whole list (which might be for a vast number of files)? If that's the case, you'd expect a larger delay each time you scroll the list too, at least until all the rows of the underlying table have been populated. It might be possible to work out what's going on by running the panel's logic under dialog test, if you breakpoint on various table services. -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF dsn sort
I've never noticed the behavior, but now that the OP has pointed it out, the reading-the-list-again explanation doesn't satisfy me. If there's a delay and a progress bar when reading the list to do the sort, why is there no similar delay when scrolling right to see the data which (according to this explanation) has not yet been collected? I'm not buying it. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Our world is not divided by race, color, gender, or religion. Our world is divided into wise people and fools. And fools divide themselves by race, color, gender, or religion. -Mohamad Safa */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Tuesday, October 13, 2020 13:12 This is one of those IIRC posts. I think this behavior goes back decades. The reason is as Kolusu states. Moreover--IIRC--the very appearance of the 'progress bar' was in response to what could be a long delay. Delay to the point that the user might suspect that the process was hung outright. I remember when the bar was introduced with that very explanation. Everything in those distant days was slower than today. As for the difference in processing, I could imagine an RFE asking for a 'quick sort' based only on the data previously collected and displayed. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sri h Kolusu Sent: Tuesday, October 13, 2020 9:47 AM 3.4 listing shows the list of datasets sorted on the Dataset name by default. Now when you issue SORT DSORG command , ISPF needs to read in the list once again and make DSORG as the primary key and then present you the list sorted on that order. You will -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: Tuesday, October 13, 2020 11:18 This is something that has puzzled me for years. I can use ISPF 3.4 to display a set of data sets. If I scroll right then I am shown the space usage figures. Scroll right again and I am shown the DSORG, RECFM, Lrecl and Blksize. If I now enter SORT DSORG I am presented with a progress bar and I am informed that information is being collected to perform the sort. Given that the DSORG was already displayed, why does ISPF go and collect the same information again? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HSM problem
Hi, I found the problem. OAM wasn't active for some reason. Once I started it, everything started working. -Original Message- From: IBM Mainframe Discussion List On Behalf Of retired mainframer Sent: Thursday, October 15, 2020 11:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: HSM problem What values are assigned to the CDSVERSIONBACKUP sub-parameters? Are they the same as the SYSUT2 DD statement in your IEBGENER job? > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gadi Ben-Avi > Sent: Thursday, October 15, 2020 1:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: HSM problem > > Hi, > We're installing HSM on a new z/OS v2.4 partition. > HSM starts and seems to be OK. > When I issue the F HSM,BACKVOL CDS command, I get: > ARC0744E MCDS COULD NOT BE BACKED UP, RC=0024, 677 ARC0744E (CONT.) > REAS=. MIGRATION, BACKUP, FRBACKUP, DUMP, AND ARC0744E (CONT.) > RECYCLE HELD. > > RC 24 says that a scratch tape could not be allocated. > > When I run a simple IEBGENER job to write to tape, there are no problems. > > What can the problem be? > > Gadi > > > -- > 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: INTRDR and submitted JobID
I did this years back and I think I used the ACB interface and ENDREQ. This link may help; https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa600/iea3a6_Obtaining_a_job_identifier.htm On Wed, Oct 14, 2020 at 10:44 PM Seymour J Metz wrote: > Originally it was the Reader/Interpreter. In MVS it is JES2 and JES3. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Pew, Curtis G [curtis@austin.utexas.edu] > Sent: Wednesday, October 14, 2020 5:37 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: INTRDR and submitted JobID > > On Oct 14, 2020, at 4:33 PM, Paul Gilmartin < > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > > > I wish JCL had never provided > >//SYSIN DD * Generated Statement > > > > Isn’t it JES2 that does that? > > > -- > Pew, Curtis G > curtis@austin.utexas.edu > > > > > > > -- > 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 > -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HSM problem
What values are assigned to the CDSVERSIONBACKUP sub-parameters? Are they the same as the SYSUT2 DD statement in your IEBGENER job? > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gadi Ben-Avi > Sent: Thursday, October 15, 2020 1:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: HSM problem > > Hi, > We're installing HSM on a new z/OS v2.4 partition. > HSM starts and seems to be OK. > When I issue the F HSM,BACKVOL CDS command, I get: > ARC0744E MCDS COULD NOT BE BACKED UP, RC=0024, 677 > ARC0744E (CONT.) REAS=. MIGRATION, BACKUP, FRBACKUP, DUMP, > AND > ARC0744E (CONT.) RECYCLE HELD. > > RC 24 says that a scratch tape could not be allocated. > > When I run a simple IEBGENER job to write to tape, there are no problems. > > What can the problem be? > > Gadi > > > -- > 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
HSM problem
Hi, We're installing HSM on a new z/OS v2.4 partition. HSM starts and seems to be OK. When I issue the F HSM,BACKVOL CDS command, I get: ARC0744E MCDS COULD NOT BE BACKED UP, RC=0024, 677 ARC0744E (CONT.) REAS=. MIGRATION, BACKUP, FRBACKUP, DUMP, AND ARC0744E (CONT.) RECYCLE HELD. RC 24 says that a scratch tape could not be allocated. When I run a simple IEBGENER job to write to tape, there are no problems. What can the problem be? Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
