PUTDOC
http://techsupport.services.ibm.com/server/nav/zSeries/putdoc/putdoc.html
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Bruce Black
Sent: Sunday, September 04, 2005 11:27 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DUMP Datasets
On Wed, 7 Sep 2005 10:10:58 EDT, Ben Alford wrote:
I've discovered that IBM's FTP doesn't require NUM OFF if each line is
terminated with a semicolon. Example:
//INPUTDD *
testcase.boulder.ibm.com (timeout 720 ;
anonymous
In [EMAIL PROTECTED], on 09/07/2005
at 12:33 AM, Robert A. Rosenberg [EMAIL PROTECTED] said:
Since the Attachment is defined as External, it does not get uploaded
to the SMTP Server and thus does not travel with the message.
Then it's not an attachment and you still have to deal with the
I've discovered that IBM's FTP doesn't require NUM OFF if each line is
terminated with a semicolon. Example:
//GO EXEC PGM=IKJEFT01,DYNAMNBR=20,PARM='FTP (EXIT TIMEOUT 360',
// REGION=3M
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
//INPUTDD *
In a recent note, Ben Alford said:
Date: Wed, 7 Sep 2005 10:10:58 EDT
I've discovered that IBM's FTP doesn't require NUM OFF if each line is
terminated with a semicolon. Example:
//INPUTDD *
testcase.boulder.ibm.com (timeout 720 ;
anonymous
On Wed, 2005-09-07 at 08:40 -0600, Paul Gilmartin wrote:
NUM OFF certainly seems to me the more comfortable solution:
Heretofore we have wrapped control statements in an IEBGENER step,
stripping out columns 73-80. Then if somebody (re)sequences the member,
we don't care much.
The semicolon
In a message dated 9/7/2005 9:41:28 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
set it once in profile, never wory about it again; and avoid
one (or several) keystrokes in each line.
Sort of like spell-checkers, sometimes they get turned off!
Some of the CUT/PASTE macros
I've discovered that IBM's FTP doesn't require NUM OFF if each line is
terminated with a semicolon.
...
I haven't used anything but NUM OFF for years.
My EDIT profile turns it off, on anything that has it on, automatically.
-teD
In God we Trust!
All others bring data!
-- W. Edwards Deming
In [EMAIL PROTECTED], on 09/06/2005
at 06:56 AM, Paul Gilmartin [EMAIL PROTECTED] said:
I don't understand the architecture here. Is SNA a layer under NJE?
Not exactly; NJE is a protocol that could run over BSC, CTCA or SNA[1]
connections. IBM has added native TCP/IP as a fourth transport
In [EMAIL PROTECTED], on 09/06/2005
at 10:12 AM, Ed Finnell [EMAIL PROTECTED] said:
Almost as bad as it's partner in crime SP 1.2!
SP 1.2 was much later than DF/EF. DF/EF came out at about the same
time as DF/DS, and before MVS/SP.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
In [EMAIL PROTECTED],
on 09/04/2005
at 12:00 AM, Ted MacNEIL [EMAIL PROTECTED] said:
ICF came out with either XA or SP1.3.x.
Much earlier; it came with DF/EF. Fortunately I missed out on *that*
horror show.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see
In [EMAIL PROTECTED], on 09/04/2005
at 04:42 PM, Robert A. Rosenberg [EMAIL PROTECTED] said:
It seems to me that sending the dump as an Email Attachment as
opposed to an FTP would solve this issue of having to monitor the
FTP.
No; it would almost certainly exceed size limits every step of
In a recent note, Shmuel Metz (Seymour J.) said:
Date: Tue, 6 Sep 2005 07:47:24 -0300
In [log in to unmask], on 09/03/2005
at 10:47 PM, Ed Gould [log in to unmask] said:
IBM should provide, IMO, a error free (or almost) way of
transmitting dumps.
They had one: Info/Access.
In a message dated 9/6/2005 7:02:24 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
Much earlier; it came with DF/EF. Fortunately I missed out on *that*
horror show.
Almost as bad as it's partner in crime SP 1.2! Think it lasted almost a week
before the damage assessments
One tip for those trying batch FTP for the first time: make sure your ISPF EDIT
parms are set correctly (NUM OFF, I think) so that your line numbers do not
make gobbledygook of your commands. With that done, I have never had a problem
with batch FTP: it works fine and usually runs at a very
Like toss another shrimp on the bar-b... What's the @#$% a shrimp? Sound
likes Hoges was comin' the raw prawn in more ways than one.
From: Eric Bielefeld
I love your Australian sayings. Is this one common? I've never heard
it before.
Bills response is close enough to be usable -
Paul Gilmartin wrote:
I don't understand the architecture here. Is SNA a layer under NJE?
How about VTAM?
SNA is indeed a lower layer than NJE. VTAM is a subsystem that
implements SNA (e.g., LU2, LU6.2) and non-SNA (e.g., LU0) under z/OS,
z/VM, and z/VSE -- not a protocol.
Why has
On Tue, Sep 06, 2005 at 10:47:36AM -0700, Edward E. Jaffe wrote:
Why has TCP/IP so surpassed SNA?
SNA is/was proprietary while TCP/IP is/was open.
This is half of it. The other half is that SNA is designed for a world where
computing power is concentrated in a few central hosts, while TCP/IP is
ICF came out with either XA or SP1.3.x.
Much earlier; it came with DF/EF. Fortunately I missed out on *that*
horror show.
...
I remember it was between NOV81 AUG84.
Because that was my first job as a perf/cap analyst, and we had to 'evaluate'
the effect of changing.
Our departmental high level
Jay Maynard wrote:
On Tue, Sep 06, 2005 at 10:47:36AM -0700, Edward E. Jaffe wrote:
Why has TCP/IP so surpassed SNA?
SNA is/was proprietary while TCP/IP is/was open.
This is half of it. The other half is that SNA is designed for a world where
computing power is concentrated
At 07:42 -0300 on 09/06/2005, Shmuel Metz (Seymour J.) wrote about
Re: DUMP Datasets and SMS:
In [EMAIL PROTECTED], on 09/04/2005
at 04:42 PM, Robert A. Rosenberg [EMAIL PROTECTED] said:
It seems to me that sending the dump as an Email Attachment as
opposed to an FTP would solve
On Sep 4, 2005, at 3:42 PM, Robert A. Rosenberg wrote:
At 22:47 -0500 on 09/03/2005, Ed Gould wrote about Re: DUMP Datasets
and SMS:
IBM should provide, IMO, a error free (or almost) way of transmitting
dumps.
It seems to me that sending the dump as an Email Attachment as opposed
VSAM hasn't had volume ownership since the advent of ICF. I was still an
applications (Cobol) programmer then, MVS 5.1 or earlier. Sometime in
the 80's
...
ICF came out with either XA or SP1.3.x.
Either way, much earlier than 5.1.
-teD
In God we Trust!
All others bring data!
-- W. Edwards
On Sep 4, 2005, at 12:57 AM, Gibney, David Allen,Jr wrote:
FTP to/from IBM is almost completely painless these days. If you do
it with a batch job direct from z/OS, well, I've not had it fail,
except
for typos.
Whenever I have tried it it took me 2-3 hours of fiddling. I guess some
Ed Gould wrote
I always disliked the IPCS handling of dumps.
It was just never (to me) a straight forward invocation like AMDPRDMP.
I fought it until the bitter end. Maybe because I was missing SHARE a
lot and never got to any of the sessions. That and I have a gut
instinct not to like VSAM.
IBM should provide, IMO, a error free (or almost) way of transmitting
dumps.
IBM provides a CLIST PUTIBM for sending doc. It prompts you for the
dataset name, and the PMR number, and submits a batch FTP job to terse
and transfer the file. I have used it for several years, I have never
had
Eric Bielefeld wrote:
I'm still working in the field, but I didn't know you could FTP dumps
to IBM via batch, as someone in this thread mentioned.
It's trivial. Here is JCL I used a couple of weeks ago to send a dump to
IBM:
//FTP2MVS JOB 1,JAFFE,CLASS=A,MSGCLASS=T,NOTIFY=SYSUID
// EXEC
From: Eric Bielefeld
I love your Australian sayings. Is this one common? I've never heard
it before.
Bills response is close enough to be usable - espicially the cat's meow
bit.
I wouldn't countenance any variant spelling of Aus.
Due to the insidious spread of American (as in USA) TV, the
On Sep 2, 2005, at 5:24 AM, Robert Wright wrote:
Somewhere in the mists of time I got the idea that multi-volume (or
stripped) dumps were not supported. I think I ran into this 10 years
ago (before stripping). Was that ever the case?
I vaguely recall having a dump that needed several volumes
From: Ed Gould
That sounds about right. I always disliked the IPCS handling of dumps.
It was just never (to me) a straight forward invocation like AMDPRDMP.
I fought it until the bitter end.
Say what
Ignore him Bob - IPCS is the ducks nuts.
I couldn't exist (professionally) without
On Sep 3, 2005, at 10:09 PM, ibm-main wrote:
-SNIP
Say what
Ignore him Bob - IPCS is the ducks nuts.
Don't get me wrong its OK but give me AMDRDMP anyday.
I know there are things you can do in IPCS that its difficult the old
way
Giovanni,
I am curious. In the past I have had some very bad experiences with
dynamic dumps.
How do you take care of a system that is creating an extreme number of
dumps?
In order to protect the systems, I am still running with 3 dump dsns per
system.
If they fill up, automation will reply
On Friday 02 September 2005 09:20 am, Schramm, Rob wrote:
Giovanni,
I am curious. In the past I have had some very bad experiences with
dynamic dumps.
How do you take care of a system that is creating an extreme number of
dumps?
How about issuing a CD SET,NODUMP command. From the doc it
Thanks for the detailed explanations Bob!
On Thu, 1 Sep 2005 20:17:37 -0400, Robert Wright [EMAIL PROTECTED] wrote:
I've heard 2nd-hand that DFHSM restrictions may influence your decision
regarding use of striping and multi-volume data sets for your inventory,
but that's not my area of
I've heard 2nd-hand that DFHSM restrictions may influence your decision
regarding use of striping and multi-volume data sets for your inventory,
but that's not my area of expertise. Hopefully, some others who follow
IBM-MAIN can supply some information on that front.
Bob Wright - z/OS MVS
Discussion List [SMTP:[EMAIL PROTECTED] On Behalf Of
Giovanni Cerquone
Sent: Friday, September 02, 2005 2:35 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DUMP Datasets and SMS
I've heard 2nd-hand that DFHSM restrictions may influence your decision
regarding use of striping and multi
Rob;
DFHSM allows you to migrate the dumps datasets very agrresively if you
code MC and SG properly.
Also, don't try to save dasd space for dumps bacause there are cases when
an error is not easily recreable. I have 10 3390-9 for production dumps,
even the SG was defined with 20. Wasting space?,
Giovanni wrote:
I've been using SMS for Dump datasets very succesfully but without using
some of the SMS features. I read about stripping, compress and extended
format but I've never read about multivol capability. Is there any sense
to think in multivol if we use stripping?. What would
On Sep 1, 2005, at 7:17 PM, Robert Wright wrote:
Giovanni wrote:
I've been using SMS for Dump datasets very succesfully but without
using
some of the SMS features. I read about stripping, compress and
extended
format but I've never read about multivol capability. Is there any
sense
39 matches
Mail list logo
