On this side of the Atlantic it was always '10, 11, 0...' not '12, 11,
0...'
I've no idea why.
John
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Clark Kidd
Sent: 28 May 2009 20:35
To: IBM-MAIN@bama.ua.edu
Subject: Punched Card
Wow...sounds like Dual Copy, but for tape.
--
All the best,
Scott T. Harder
On 5/28/09, O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov wrote:
Thanks Allan, I finally found the section you were quoting and after reading
concede your point.
I've learned something so the day is not a
I suspect DTSC systems were upgraded from earlier releases and this
thus didn't get installed. Does that make more sense?
No. That is only possible if they have a pre-GA copy of the operating
system. Otherwise it is not possible.. My point remains. If there is an
IEFACTRT exit routine that is
c...@belastingdienst.nl wrote:
Hello, all
I have a problem using OpenSSH (from the IBM delivered Ported Tools)
with z/OS 1.10. I cannot open a ssh session on one of our sysplexes. I
scanned the syslogd log file and this says:
fatal: ssh-rand-helper child produced insufficient data.
On
This was definitely a wetware problem. (I forgot to sort by name first
to look for duplicates. Color my face red this morning.)
Sorry about that; here's a corrected list. In the process of correcting
it, I found there are really 38 items on the list. Also, I got one more
response, and
Wow, the replies to my query were overwhelming! Perhaps I should change
the subject line to Book on Poughkeepsie! grin
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Richards, Robert B.
Sent: Thursday, May 28, 2009 12:16 PM
To:
OK, so here is the final diagnosis: They had an error in their automated
build process that was causing the programs to be translated by the CICS
translator, which prefixed the LINKAGE SECTION with the CICS EIB area. That
meant that the LINKAGE section mapping didn't match the actual passed in
I verfied the STC. The CDS backups were successfully executed at 05:01 a.m.:
ARC0741I CDS BACKUP ENDING AT 05:01:18 ON 2009/05/29,
ARC0741I (CONT.) STATUS=SUCCESSFUL
I checked the status - HSEND Q AC W it displays the following:
BACKUP=1895. Of note the backup is not
Willie,
Kindly post the following from your Q AC
ARC0163I BACKUP=NOT HELD, AUTOBACKUP=NOT HELD, RECOVERY=NOT HELD,
ARC0163I (CONT.) TAPEDATASETRECOVERY=NOT HELD, DATA SET BACKUP=NOT HELD, VOLUME
ARC0163I (CONT.) BACKUP=INACTIVE, DATA SET RECOVERY=INACTIVE, VOLUME
Here it is:
ARC0101I QUERY ACTIVE COMMAND STARTING ON HOST=G
ARC0144I AUDIT=NOT HELD AND INACTIVE, LIST=NOT HELD AND INACTIVE, RECYCLE=NOT
ARC0144I (CONT.) HELD AND ACTIVE, REPORT=NOT HELD AND INACTIVE
ARC0160I MIGRATION=NOT HELD, AUTOMIGRATION=NOT
Willie,
Issue a HSEND QUERY SETSYS and let me know what the following fields contain:
MAXBACKUPTASKS=??
DATA SET DASD BACKUP TASKS=??
DATA SET TAPE BACKUP TASKS=??
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
willie
Does anyone have a reasonably good idea of
a) how many active VSE shops there are worldwide?
b) how many VSE shops have any RPGII code in production?
Thanks
Bill
--
For IBM-MAIN subscribe / signoff / archive access instructions,
Willie,
In your listing it shows
DATA SET BACKUP=DASD HELD,
Do you want this held?
Lizette
Here it is:
ARC0101I QUERY ACTIVE COMMAND STARTING ON HOST=G
ARC0144I AUDIT=NOT HELD AND INACTIVE, LIST=NOT HELD AND INACTIVE, RECYCLE=NOT
ARC0144I (CONT.) HELD AND
Did you happen to read the last issue of z/OS Hot Topics? I think you'll be
pleasantly surprised by the story of page 4. It's the first is our series.
Our next issue comes out in August with more in the series. We are also
publishing another installment on the Website in June.
Here's a link to
Here it is:
ARC0154I MAXBACKUPTASKS=01, ABSTART= (0500 0700 0730), VERSIONS=002,
ARC0269I DATA SET DASD BACKUP TASKS=02
DATA SET TAPE BACKUP TASKS=00,
--- On Fri, 5/29/09, Richards, Robert B. robert.richa...@opm.gov wrote:
From: Richards, Robert B. robert.richa...@opm.gov
Subject: Re:
Hmmm I checked the DFHSM parms but I don't see it being held. I am not
sure how or why it is being held.
--- On Fri, 5/29/09, Lizette Koehler stars...@mindspring.com wrote:
From: Lizette Koehler stars...@mindspring.com
Subject: Re: DFHSM QUESTION - UNABLE TO BACKUP DSN
To:
Willie,
Do you have anything coded in your parmlib for DSBACKUP?
I don't and the defaults work fine.
Kindly post the following from Q SETSYS
ARC0269I DATA SET DASD BACKUP TASKS=02 DATA SET TAPE BACKUP TASKS=02,
ARC0269I (CONT.) DEMOUNTDELAY MINUTES=0060, MAXIDLETASKS=00, DATA SET
David,
I did a find for DSBACKUP and all I found is :
SETSYS DSBACKUP(DASDSELECTIONSIZE(85 00) DASD(TASKS(2)) -
TAPE(TASKS(0) DEMOUNTDELAY(MINUTES(0) MAXIDLETASKS(0
--- On Fri, 5/29/09, O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov
wrote:
From: O'Brien, David
Well you will never backup to tape as you have Tape(tasks(0).
Hope you have sufficient ML1 space once you release DSBACKUP. As Lizzette
pointed out, it is currently held.
Dave O'Brien
NIH Contractor
From: IBM Mainframe Discussion List
Willie,
Issue RELEASE BACKUP(DSCOMMAND) and let us know if that changes things.
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Lizette Koehler
Sent: Friday, May 29, 2009 10:12 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: DFHSM
David,
Just to confirm my understanding if I change the TAPE(TASKS(1) this should
solve the problem. Do I need to change anything else?
--- On Fri, 5/29/09, O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov
wrote:
From: O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov
Subject:
Willie,
If you want Dataset Backups by command to go to tape then yes you need to
change Tape(task(n) to a value other than zero.
Then Release Backup(dscommand) as Bob suggested in another posting.
Dave O'Brien
NIH Contractor
From: IBM Mainframe
Bob,
I will need to rethink RELEASE BACKUP(DSCOMMAND). I am not sure why there is a
TAPE(TASKS(0).
If I issue the RELEASE BACKUP(DSCOMMAND) then I could have a problem with DASD
(as per David's warning).
--- On Fri, 5/29/09, Richards, Robert B. robert.richa...@opm.gov wrote:
From:
David,
Should I need to change anytthing in the SETSYS
DSBACKUP(DASDSELECTIONSIZE(85 00) DASD(TASKS(2)) ?
--- On Fri, 5/29/09, O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov
wrote:
From: O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov
Subject: Re: DFHSM QUESTION -
Complely off topic, but I can't resist
The refrence to toll collection harkens me back to the NY State
Thruway (a sort of Poughkeepsie relationship there, so maybe not so
off topic). I was born and raised in Saugerties, NY, which is just
north of Poughkeepsie; triangular to Kingston and
Wow, the replies to my query were overwhelming!
Perhaps I should change the subject line to Book on Poughkeepsie!
Nobody is required to respond; we're all volunteers.
Maybe nobody has the answer, or they are busy.
-
Too busy driving to stop for gas!
The 850MB value that you have specified allows a 850MB dataset backup to be
directed to ML1 DASD.
You might want to make that value smaller.
Or comment out the Setsys Dsbackup altogether and take the defaults.
Section 3.37.5.53 DSBACKUP: Controlling the Command Data Set Backup
Environment of
Hi
Seems to me as standard ISPF table, and the KEY is the FMID. You can get
the row's via TBGET
Richards, Robert B. wrote:
Does anyone have any REXX code to grab English description FMID table
entries out of GIM.SGIMTENU's BCNFMDS member by passing it the FMID in
question?
I am writing
Really Ted? Did you really think that I did not know that after all my
years on this list? Lighten up! Can't you spot a tongue-in-cheek post
when you see one?
Bob
-
-Original Message-
From: IBM Mainframe Discussion List
This worked for me:
/* REXX */
ADDRESS TSO
ALLOC FI(ISPPROF) DA('ESA.ISPF.ISPPROF') SHR REUSE
ADDRESS ISPEXEC
Really Ted? Did you really think that I did not know that after all my years
on this list? Lighten up! Can't you spot a tongue-in-cheek post when you see
one?
And, when I said maybe nobody knows, how serious was I.
-
Too busy driving to stop for gas!
Okay. Point taken. Truce! TGIF! :-)
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ted MacNEIL
Sent: Friday, May 29, 2009 11:41 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: FMID descriptions
Really Ted? Did you really think that I did not
David,
I found in the doc that both options can be used in the DFHSM STORAGE
ADMINISTRATION REFERENCE ZOS V1R70. I will take a closer look at this option.
Since the DATASET BACKUP option is held, can I assume if I issue the RELEASE
BACKUP(DSCOMMAND), the datasets will be backed up to ML1 DASD
Thank you, Miklos. I appreciate your response.
Bob
-
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Miklos Szigetvari
Sent: Friday, May 29, 2009 11:40 AM
To: IBM-MAIN@bama.ua.edu
Since the DATASET BACKUP option is held, can I assume if I issue the
RELEASE BACKUP(DSCOMMAND), the datasets will be backed up to ML1 DASD since
the TAPE(TASKS is set to (0).
IMHO ... Yes, but ...
What if a dataset backup request exceeds 850MB or the max. space available
on a single ML1 disk?
That would be my understanding.
Dave O'Brien
NIH Contractor
From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of willie
bunter [williebun...@yahoo.com]
Sent: Friday, May 29, 2009 11:49 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: DFHSM
Ulrich,
While I agree with you that backups to tape should be allowed, if a backup
fails to ML1 due to lack of space won't the request fail and the next backup in
the queue be executed? That is what I would expect.
Dave O'Brien
NIH Contractor
From: IBM
Thanks to everybody who responded to my post and help fix my problem. You are
all a shining example of what a great group you are. Much obliged. Cheers.
--- On Fri, 5/29/09, Ulrich Krueger u...@pacbell.net wrote:
From: Ulrich Krueger u...@pacbell.net
Subject: Re: DFHSM QUESTION - UNABLE TO
The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
jever...@us.ibm.com (Jodi Everdon) writes:
Did you happen to read the last issue of z/OS Hot Topics? I think you'll be
pleasantly surprised by the story of page
Dave,
I can't prove it, because I don't have access to a mainframe right now.
However, I seem to remember a situation some years back, where a failed
command got stuck on top of the queue and caused the function to be held. If
you released the function, the failed command would attempt to execute
You're very welcome, Willie.
Are you saying that the problem is now fixed?
What did you do? What changes did you make?
And, for the curious among us: What caused dataset backup to be held in the
first place? A dataset too big for disk backup or lack of ML1 space?
Regards,
Ulrich Krueger
Okay. Point taken. Truce! TGIF! :-)
Truce.
It's sometimes hard to tell how serious people aren't from the written word.
I forgot to include a smiley.
I have a custom-designed one:
(8-{]}
Bald head, glasses, nose, mustache, smile, beard.
-
Too busy driving to stop for gas!
2009/5/28 Richards, Robert B. robert.richa...@opm.gov
Does anyone have any REXX code to grab English description FMID table
entries out of GIM.SGIMTENU's BCNFMDS member by passing it the FMID in
question?
I am writing some code to parse information from the ERROR SYSMODS
Report and want to
I have made a request to change the option to use TAPE(TASKS(1)). It seems
that this problem has been always there - inherited it from a client who came
on board 2 years ago.
If I get the green light from the client, I will change the TAPE(TASKS to (1)
and issued the RELEASE
Tony,
I'll definitely look into that web link. In the meantime, thanks to
Miklos and especially to Bob Rutledge, I have a working solution that I
can modify to suit my own purposes.
Now, I wonder if Kurt will chime in? grin
Bob
-
Do I need to hard the command in the PARMLIB?
Willie,
AFAIK, you can issue a HSEND SETSYS ... to make the change on the fly.
But, for the change to be valid beyond the next IPL (or DFHSM restart), you
need to update your ARCCMDxx in PARMLIB.
While you're in there, review the command options and
On Fri, 29 May 2009 17:40:07 +0200, Miklos Szigetvari
miklos.szigetv...@isis-papyrus.com wrote:
This worked for me:
/* REXX */
ADDRESS TSO
ALLOC FI(ISPPROF) DA('ESA.ISPF.ISPPROF') SHR REUSE
ADDRESS ISPEXEC
TBOPEN BCNFMDS NOWRITE
TBTOP BCNFMDS
DO WHILE RC = 0
TBSKIP BCNFMDS
TBGET
Ulirich.
Thanks for the sound advice. I will adhere to it. Thanks again.
--- On Fri, 5/29/09, Ulrich Krueger u...@pacbell.net wrote:
From: Ulrich Krueger u...@pacbell.net
Subject: Re: DFHSM QUESTION - UNABLE TO BACKUP DSN - THANK YOU
To: IBM-MAIN@bama.ua.edu
Received: Friday, May 29, 2009,
On 28 May 2009 08:21:54 -0700, z...@cdc.gov (Burrell, C. Todd ,
CDC/OCOO/ITSO, CTR) wrote:
I would think that running these same procs over and over in the same
job would make the finders file pretty useless? I would think you
would want a second step to process the finders file, and then
I mentioned this case to a co-worker and she had a problem which was
harder to figure out.
Some user wrote some jobs which had EasyTrieves followed by copying
the temporary file to tape. The process didn't make much sense, and
was without error checking.
But the odd thing was, when he ran
I changed the names of finders to be unique in each proc as the simplest
solution to this problem.
I stopped specifying the name, at all, for temp files.
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff
On 28 May 2009 08:24:20 -0700, d...@lists.duda.com (David Andrews)
wrote:
Use referbacks in your receiving steps (DSN=*.stepname.ddname) instead
of temporary dataset names (DSN=name). They're a bit awkward, but
eliminate the duplicate dataset name issue. Quoting the JCL Reference:
To ensure
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Howard Brazee
Sent: Friday, May 29, 2009 12:40 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Duplicate temp file
I mentioned this case to a co-worker and she had a problem which was
Trouble is - those procs usually run in their own jobs.
I don't understand what you're trying to say.
What is the problem with PROCs running in their own jobs?
Not assigning names to a DD shouldn't be an issue in this case.
-
Too busy driving to stop for gas!
On 28 May 2009 12:11:33 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote:
We Mac's get it all the time.
Mc is more common.
Also, lots of people don't capitalise the N.
Not to mention software.
--
For IBM-MAIN subscribe / signoff /
On Fri, 29 May 2009 12:51:04 -0500, McKown, John jmck...@healthmarkets.com
wrote:
The second temporary file likely got the same extents as a previous
temporary file. But I thought that SMS now forced an EOF to be written at
allocation time. Are your temporary volumes not SMS managed? I know that
... I looked at the various SMP/E LIST commands, but parsing any one of
those reports seems to be overkill for my purposes.
You could do UNLOAD FUNCTIONS instead of LIST and that output should be
much easier to parse.
Kurt Q, feel free to jump in here and tell me that it is possible run
On 29 May 2009 10:54:49 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote:
Trouble is - those procs usually run in their own jobs.
I don't understand what you're trying to say.
What is the problem with PROCs running in their own jobs?
Not assigning names to a DD shouldn't be an issue in this
I guess I don't understand. The temp file doesn't need a name?
Not specified in the JCL.
//TEMP DD UNIT=DISK,SPACE=(CYL,(5,3))
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff / archive access
2009/5/29 Jodi Everdon jever...@us.ibm.com
Did you happen to read the last issue of z/OS Hot Topics? I think you'll be
pleasantly surprised by the story of page 4. It's the first is our series.
Our next issue comes out in August with more in the series. We are also
publishing another
On Fri, 2009-05-29 at 15:14 -0400, Howard Brazee wrote:
The temp file doesn't need a name?
That's exactly correct! Example:
//STEP1 EXEC PGM=IEFBR14
//SENDER DD UNIT=SYSDA,SPACE=(TRK,1),DISP=(,PASS)
//STEP2 EXEC PGM=IEFBR14
//RECEIVER DD DSN=*.STEP1.SENDER,DISP=(OLD,DELETE)
--
David Andrews
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Kurt Quackenbush
Sent: Friday, May 29, 2009 1:43 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: FMID descriptions
... I looked at the various SMP/E LIST commands, but
parsing any
On Fri, 29 May 2009 12:54:36 -0500, John McKown @SWBELL.NET wrote:
On Fri, 29 May 2009 12:51:04 -0500, McKown, John @HEALTHMARKETS.COM
You figured out how to circumvent the HIPAA noise?
wrote:
The second temporary file likely got the same extents as a previous
temporary file. But I thought
And since then, and yet, I wonder why IBM doesn't DTRT and modify allocation
to unconditionally write an EOF, regardless
of DSORG, SMS, whatever. Are they fearful of the performance impact?
What's the EOF on a PDS?
PDSE?
Indexed VSAM?
There are issues!
-
Too busy driving to stop for gas!
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin
Sent: Friday, May 29, 2009 2:58 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Duplicate temp file
On Fri, 29 May 2009 12:54:36 -0500, John McKown @SWBELL.NET wrote:
On
On 29 May 2009 12:30:59 -0700, d...@lists.duda.com (David Andrews)
wrote:
On Fri, 2009-05-29 at 15:14 -0400, Howard Brazee wrote:
The temp file doesn't need a name?
That's exactly correct! Example:
//STEP1 EXEC PGM=IEFBR14
//SENDER DD UNIT=SYSDA,SPACE=(TRK,1),DISP=(,PASS)
//STEP2 EXEC
On Fri, 29 May 2009 20:02:54 +, Ted MacNEIL wrote:
And since then, and yet, I wonder why IBM doesn't DTRT and modify allocation
to unconditionally write an EOF, regardless
of DSORG, SMS, whatever. Are they fearful of the performance impact?
What's the EOF on a PDS?
PDSE?
Indexed VSAM?
It
At 12:29 -0400 on 05/28/2009, Ken Porowski wrote about 3592 Upgrade
in an ATL to TS1130's:
We are about to upgrade our ATL (3494) tape drives from 3592-J1A and
3592-E05 (aka TS1120) to 3592-E06 and 3592-EU6 (aka TS1130). These are
the only 3592 drives in the ATL and all are on the same
At 15:35 -0400 on 05/28/2009, Clark Kidd wrote about Punched Card
Combinations (WAS Book on Poughkeepsie):
As I remember, there were three control rows at the top of the
card (12, 11, 0) and then 9 data rows (1-9) under those. So each
possible column would contain up to 12 rows that could be
List -
When I run a DCOLLECT using the MCDS and BCDS dataset in my JCL I get the
following error message
IEC161I 009-0663,LK41591B,DCOLLECT,MCDS,,,SYS1.DFSMSHSM.MCDS
This is not making sense. I am reading the IEC161I and I am not clear on what
it is trying to say.
Any ideas?
Lizette
On Fri, 29 May 2009 17:31:17 -0400, Lizette Koehler
stars...@mindspring.com wrote:
List -
When I run a DCOLLECT using the MCDS and BCDS dataset in my JCL I get the
following error message
IEC161I 009-0663,LK41591B,DCOLLECT,MCDS,,,SYS1.DFSMSHSM.MCDS
This is not making sense. I am reading the
Are your shareoptions(2,3)?
Terry Traylor
charlesSCHWAB
TIS Mainframe Storage Management
Remedy Queue: tis-hs-mstg
(602) 977-5154
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Lizette Koehler
Sent: Friday, May 29, 2009 2:31 PM
To:
Mark Zelden wrote:
Bob and I spoke off-list about this. SMP/E is a bad spot for what he
is looking for. Too many FMIDs are part of z/OS base. For example,
RACF (HRF*).
Huh? Given the FMIDs reported by REPORT ERRSYSMODS, I thought Bob was
asking for a method to obtain the DESCRIPTION for
Robert, it's the same media type, as long as the dataclass specifies (or
allows) a recording format other than EFMT1, everything will be fine.
Robert A. Rosenberg hal9...@panix.com 05/29/09 5:07 PM
Based on the above you should also stock the ATL with EFMT2/3 media
so you can continue to
So far, I've been able to use one mod-9 for SMPNTS and one mod-9 for
SMPWKDIR, both HFS. But it does take 3 mod-3's to hold all the various
roots for z/OS.
Dave Gibney
Information Technology Services
Washington State University
-Original Message-
From: IBM Mainframe Discussion List
On Fri, 29 May 2009 18:22:11 -0400, Kurt Quackenbush wrote:
McKown, John wrote:
Could I ask a question which I know you likely cannot answer. But, if
possible, could you explain why the SMP/E Internet download stuff in
SMP/E uses UNIX files to store the data rather than z/OS legacy
type
McKown, John wrote:
Could I ask a question which I know you likely cannot answer. But, if
possible, could you explain why the SMP/E Internet download stuff in
SMP/E uses UNIX files to store the data rather than z/OS legacy
type datasets (perhaps compressed with TERSE or XMIT'ed)?
As a matter
On Fri, 29 May 2009 14:43:25 -0400, Kurt Quackenbush wrote:
Just provides FMID and DESCRIPTION? Nope, nothing that simple exists.
What fun would that be? You could of course write a program (a real
program, not REXX) that uses GIMAPI to read the zone and extract exactly
this info, but I dare say
Kurt,
I also find this a pain in the a__. Is it still IBM's purpose to 'Make this
more difficult so we will understand it' You took something that worked real
well and messed it up.
How about two procedures, one for the z/OS-z/VM and one for HFS/OMVS/UNIX
fixes???
--- On Fri, 5/29/09, Kurt
On Fri, 29 May 2009 16:00:47 -0700, Howard Rifkind wrote:
I also find this a pain in the a__. Is it still IBM's purpose to 'Make this
more difficult so we will understand it' You took something that worked real
well and messed it up.
Err... How did the earlier something work real well for
On Fri, 2009-05-29 at 17:52 -0500, Paul Gilmartin wrote:
Grrr. (Bristling at the aura of condescension.) It's an
unconscionable oversight that SMP/E elected to design GIMAPI
in a Rexx-hostile style.
I'd be prepared to cut Kurt some slack, and trust his answer was
composed with a modicum of
Scott - Somehow I missed that when I searched.
Lizette
List -
When I run a DCOLLECT using the MCDS and BCDS dataset in my JCL I get the
following error message
IEC161I 009-0663,LK41591B,DCOLLECT,MCDS,,,SYS1.DFSMSHSM.MCDS
This is not making sense. I am reading the IEC161I and I am
Wasn't IBM going to, at one point, wrap something around SMP/E so that
it essentially ran under the covers and the user had a *much*
simpler interface (so to speak)??
--
All the best,
Scott T. Harder
On 5/29/09, Paul Gilmartin paulgboul...@aim.com wrote:
On Fri, 29 May 2009 16:00:47 -0700,
On Fri, 29 May 2009, Kurt Quackenbush wrote:
snip
I'm sure we could have made other choices, and I'm sure some folks on
this list will be more than happy to point them out to me. Be that as
it may, the format we landed on was and is UNIX files. It is
unfortunate you have to jump through
At 18:14 -0400 on 05/29/2009, Scott Rowe wrote about Re: 3592 Upgrade
in an ATL to TS1130's:
Robert, it's the same media type, as long as the dataclass specifies
(or allows) a recording format other than EFMT1, everything will be
fine.
OOPS. So as the volume gets scratched, it can be
At 18:12 -0500 on 05/29/2009, Paul Gilmartin wrote about Re: SMP/E
packaging of maintence / products (was: FMID desc:
On Fri, 29 May 2009 16:00:47 -0700, Howard Rifkind wrote:
I also find this a pain in the a__. Is it still IBM's purpose to
'Make this more difficult so we will understand
good grief, why do you keep fighting with the storage admins?
make one zFS download extended format dataset on ONE permanently mounted mod
54 volume, and be done with it.
use that download file system for z/OS, cics, db2, program products, etc. Use
skulker to keep it clean of old files.
87 matches
Mail list logo
