on 5/13/05 9:22 PM, Bruce Black at [EMAIL PROTECTED] wrote:
>>
>>
>> IIRC the blksize ends up being greater than 32K (with DFDSS) and FTP drops
>> anything after 32K. The "trick" is to tell DFDSS (via blkszie=32760)" not to
>> create large blksizes.
>>
> I am not positive, but I believe that wh
Let me throw in an opinion that I have expressed before, but not for a
few years.
When SMF records are dumped from the active SMF dataset, they can be
converted to VB instead of VBS (spanned). When I researched this some
years ago I found that the SMF rules said that the largest valid SMF
rec
IIRC the blksize ends up being greater than 32K (with DFDSS) and FTP drops
anything after 32K. The "trick" is to tell DFDSS (via blkszie=32760)" not to
create large blksizes.
I am not positive, but I believe that when the output backup file is on
disk, DSS writes only blocks up to 32K in length (
on 5/13/05 3:44 PM, Volker Bandke at [EMAIL PROTECTED] wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> Low, David said the following on 05/13/2005 08:27 >It would be great if JCL
> records could extend to 32K and handle both fixed and variable length
> records. No more line co
Actually Bill,
the TRUNC option only apply for programs using MOVE or IF including literals.
So a MOVE 32767 to OsParms-Length or IF OsParms-Length > 1 might fail
depending
on the TRUNC option in this case. As the OsParm-length is currently limited
to 100 bytes it will never fail regardl
Actually Roland,
Programs written that way MAY fail with parms longer than (depending
upon TRUNC setting). I have made a number of RCF's suggesting that code
samples "like this" should change from COMP to COMP-5.
Have you seen how the current IBM documentation shows this technique? See:
Adrian,
I agree with you regarding the 32K, but after reading some posting it seems
people asking for "unlimited" parms. I also would like to see some improvements
in this
area but everything beside 256 is a nightmare for me.
Of course LE runtime overriding is an issue with some user PARM. Per
--- "Schiradin,Roland HG-Dir itb-db/dc" <[EMAIL PROTECTED]> wrote:
From: "Schiradin,Roland HG-Dir itb-db/dc" <[EMAIL PROTECTED]>
Date: Sat, 14 May 2005 00:59:54 +0200
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: PARM=
All of our Cobol programs using the PARM will fail if the parm length exceed
32767
The fact that this thread split off from the PARM= thread and then
wrapped back demonstrates something else: JCL itself is an anacronism.
In the Future Work Flow Manager ("FWFM") white paper from about 1980,
SHARE suggested that having different command languages for batch and
TSO (and whatever els
> an authorized program that breaks in any way due to a long parm was
incorrectly written in the first place
Agreed.
But that won't get your data back, or make the dumb "mainframe hacked"
stories go away.
I would say pretty much by definition all viruses exploit programs that
were "incorrectly w
On Fri, May 13, 2005 at 02:53:00PM -0700, Charles Mills wrote:
> As Gil pointed out, the ONLY new exposure is for authorized programs.
> Formerly, an authorized program could be confident that it's caller was
> either JCL or another trusted (authorized) program. It would thus be a
> reasonably val
All of our Cobol programs using the PARM will fail if the parm length exceed
32767
Linkage section.
01 OsParms.
05 OsParms-Length pic s9(4) comp.
05 OsParms-Data.
Please don't even think of it!!!
It drives me really crazy to edit some members with
lrec longer then my emulator settings. Try to insert some data e.g. a longer
path name into etc/profile using ISPF edit.
Sample
EDIT /etc/profileColumns 1 00072
> they relied on well-documented limitations which have been around for
decades.
Not so. The restriction is in JCL, not in the program entry linkage. It
has always been possible to call any program - including any program
normally executed as a jobstep program (PGM=) - and pass any length of
param
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Low, David said the following on 05/13/2005 08:27 >It would be great if JCL
records could extend to 32K and handle both fixed and variable length
records. No more line continuation ever! I just don't know if such an
enhancement is feasible.
Hmm... I
On 13 May 2005 11:21:51 -0700, in bit.listserv.ibm-main
(Message-ID:<[EMAIL PROTECTED]>)
[EMAIL PROTECTED] (Shmuel Metz , Seymour J.) wrote:
In <[EMAIL PROTECTED]>, on
05/12/2005
at 10:19 PM, "Arthur T." <[EMAIL PROTECTED]> said:
At first, I agreed with this, for two reasons
(details be
All of this is "fixed" in the 2002 COBOL Standard where *NEW* binary
data-types are introduces (with NO picture clause - just something
indicating "size" and whether or not they are signed). An existing SHARE
requirement exists for IBM to implement these. (It even includes a one-byte
binary field
On 13 May 2005 09:53:23 -0700,
[EMAIL PROTECTED] (Chase, John) wrote:
>Seems to me that allowing instream data within a PROC would add little value
>unless it was accompanied by allowing variable substitution to occur within
>the instream data. Without substitution, any change desired in the inst
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Laine, Rogers
> Sent: Friday, May 13, 2005 1:35 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Corrupted SMF record
>
>
> Hello,
>
> I have a SMF dataset that was MOD'ed to a existing dataset
on 5/13/05 1:35 PM, Laine, Rogers at [EMAIL PROTECTED] wrote:
> Hello,
>
> I have a SMF dataset that was MOD'ed to a existing dataset that is now
> corrupted using the program SMFDUMP.
> I was able to use the program IFASMFDP to create a new output dataset up
> to the corrupted record.
> My quest
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Laine, Rogers
>
> Hello,
>
> I have a SMF dataset that was MOD'ed to a existing dataset
> that is now corrupted using the program SMFDUMP.
> I was able to use the program IFASMFDP to create a new output
> dataset u
Bill Klein writes:
On the other hand, the only time that a COMP-5 data item works differently
from a BINARY or COMP (or COMP-4) item (on the mainframe) is *IF* you try
and use values greater than the PICTURE clause allows. This is an "ugly"
thing to do and is NEVER recommended.
My response is that
Peter,
I vote for extending the current JCL processing. A quick perusal of [a lot of]
our current source tells me that a) the original parm string isn't moved to an
internal program area and b) the length is checked before the parm data is parsed.
Now if the length ever gets to be bigger than 3
Hello,
I have a SMF dataset that was MOD'ed to a existing dataset that is now
corrupted using the program SMFDUMP.
I was able to use the program IFASMFDP to create a new output dataset up
to the corrupted record.
My question is how can I recover the records that are pass the bad one?
I recall see
on 5/13/05 10:49 AM, Gabe Torres at [EMAIL PROTECTED] wrote:
> Ed,
> There was no blksize info supplied in the DCB, so it must be
> defaulting to whatever ADRDSSU likes.
> gabe
>
>
Gabe,
IIRC the blksize ends up being greater than 32K (with DFDSS) and FTP drops
anything after 32K. The "trick"
> | So if your parm syntax doesn't include a handy comma
> somewhere, it can't
> | exceed one line.
>
>
> Wrong. Check JCL reference manual :)
>
> Hint: Continued line must begin exactly in col 16.
Arcane rules for line continuation like this, I can live without. Is this also
true for cont
We in the SHARE LNGC project are ALWAYS willing to accept new requirements
for LE callable service.
If you are a SHARE member, please feel free to submit such a requirement
(for accessing JCL symbolics - and/or other JCL-known "values").
"Larry Bertolini" <[EMAIL PROTECTED]> wrote in message
news
In <[EMAIL PROTECTED]>, on
05/12/2005
at 10:19 PM, "Arthur T." <[EMAIL PROTECTED]> said:
> At first, I agreed with this, for two reasons
>(details below):
>1. It obviates the buffer overflow problem.
How? If the data from the DD are moved into the first parameter with a
halfword length
In <[EMAIL PROTECTED]>, on 05/13/2005
at 01:08 AM, Leonard Woren <[EMAIL PROTECTED]> said:
>I think you had the right idea and then missed: I propose that the
>solution should be // PARM and make it mutually exclusive with the
>PARM= keyword on EXEC. Why complicate things?
That question appl
In <[EMAIL PROTECTED]>, on 05/13/2005
at 09:57 AM, David Andrews <[EMAIL PROTECTED]> said:
>Please also remember the START command processor: convince it to pass
>parameters bigger than... what, 61 bytes? (Whatever fits on a single
>generated "// PARM='...'" card image.)
S MYSTC,A=long,B=long
In <[EMAIL PROTECTED]>, on 05/13/2005
at 09:06 AM, Paul Gilmartin <[EMAIL PROTECTED]> said:
>Otherwise, I wonder how the PARM is represented while a job is in the
>input queue? Does it reside in a control block? Is the structure of
>that block documented as a programming interface? Is there a
In <[EMAIL PROTECTED]>,
on 05/12/2005
at 04:09 PM, Raymond Noal <[EMAIL PROTECTED]> said:
>Instead of messing around with the PARM= field, how about adding a
>new one like zPARM= (since these are the days of z/OS, z/VM, z/Linux
>and (soon to be) z/TPF on our new z/Series processors). Have zPARM
If anyone on this list works for Bank of Switzerland,
I would be interested in off-list discussions of a
project I heard about where one or more applications
were moved off of UNIX servers onto a mainframe.
If anyone else has done this kind of conversion, I
would also be interested in hearing from
In a recent note, Chase, John said:
> Date: Fri, 13 May 2005 11:53:10 -0500
>
> Seems to me that allowing instream data within a PROC would add little value
> unless it was accompanied by allowing variable substitution to occur within
>
I agree that variable substitution in instream data
No - it has to do with full surround sound - 360 degrees.
Three on-board processors.
Wonder how many MIPS that is? :)
M.
---
Michael S Hines
[EMAIL PROTECTED]
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
There's a neat idea. The JES spool can handle longer than 80 characters for
data sets.
I haven't tried it, but can one use the VSAM interface to the INTRDR and put
in records > 80 characters? Variable-length characters?
Later,
Ray
-Original Message-
From: IBM Mainframe Discussion Lis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
|
| This list's contributors had to enlighten me, once. They fixed that a
| while back:
They fixed it? Wasn't it this way since the dawn of time?
- --
~ With kind Regards|\ _,,,---,,_
~ZZZzz /,`.-'`'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
|
| So if your parm syntax doesn't include a handy comma somewhere, it can't
| exceed one line.
Wrong. Check JCL reference manual :)
Hint: Continued line must begin exactly in col 16.
- --
~ With kind Regards|\ _,,,---,,_
~
I like most have had to deal with the strange limit of 100 characters on the
PARM statement. I would support raising the limit in any way that would not
break the old programs still running. That is the passing of the PARM value
should be done in the same way as today. This way, current programs
Whatever is done, please remember CEE3PRM (and existing SHARE requirement
SSLNGC0313586) - and of course the fact that LE "claims" that this works the
same under z/OS and VM. (VSE already addressed this via the new CEE5PRML
callable service. See:
http://publibfp.boulder.ibm.com/cgi-bin/bookmg
256 seems WAY to small to me - for such things as the LE ENVAR run-time
option.
(In fact, just trying to pass all the LE run-time options that one MIGHT
want to override - without a CEEUOPT makes me question 4096)
"Ed Gould" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> on 5/
Miller, Pat wrote:
> Is there a utility that examines OS/VS COBOL source files and provides
> a summary of just how much code needs to be altered for Enterprise
> COBOL? Something a little more concise and less cumbersome than
> output from the new compiler, I mean.
http://gsf-soft.com/Products/C
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Taddei, Cathy
>
> Thank you, Eric, that is indeed what I meant -- you cannot
> place DD * before the PEND statement, or anywhere in a
> proclib member. And it is still a restriction in z/OS 1.4,
> producing error m
Thank you, Eric, that is indeed what I meant -- you cannot place DD *
before the PEND statement, or anywhere in a proclib member. And it is
still a restriction in z/OS 1.4, producing error message:
IEFC601I INVALID JCL STATEMENT
if you put DD * in a proc. And I agree with everyone that said the
The Wall Street Journal (and other news media) reported today on
Microsoft's new game system: the "Xbox 360".
http://online.wsj.com/article/0,,SB111592630884332003,00.html?mod=home_whats_news_us
When I first saw the WSJ article, I couldn't help wondering if the "360"
part of the name is pure coi
On May 13, 2005, at 11:29 AM, Eric Chevalier wrote:
On 13 May 2005 06:06:09 -0700,
[EMAIL PROTECTED] (Chase, John) wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Taddei, Cathy
I agree with Gil and Charles. IMO, a DD statement would be
pointless.
If a programmer
ADRDSSU should have created a RECFM=U LRECL=0 dataset if it defaulted.
If so, transmit it to the mainframe as FB,80 then browse it in hex. Column 30
should have a halfword with the original blocksize. Then send it again with
that BLKSIZE and RECFM=U LRECL=0
-
This e-mail message is for the so
In a recent note, Bruce Black said:
> Date: Fri, 13 May 2005 11:48:02 -0400
>
> There is one limitation with coding a PARM on multiple lines (to get to
> the 100 char limit): You must use a comma to cause continuatoin, and
> the comma is passed as part of the parm.
>
This list's contri
Thomas,
Have you tried this with a ADRDSSU physical dump, or a logical
dump,...or does it matter.??
Thanks,
gabe
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Thomas Conley
Sent: Thursday, May 12, 2005 9:19 PM
To: IBM-MAIN@BAMA.UA.EDU
Sub
Ed,
There was no blksize info supplied in the DCB, so it must be
defaulting to whatever ADRDSSU likes.
gabe
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ed Gould
Sent: Thursday, May 12, 2005 7:50 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re:
There is one limitation with coding a PARM on multiple lines (to get to
the 100 char limit): You must use a comma to cause continuatoin, and
the comma is passed as part of the parm.
For example,
//PARM=('ASDFQWER34234',
// 'XCVSDF')
will be passed as ASDFQWER34234,XCVSDF
So if your
In a recent note, [log in to unmask] said:
> Date: Fri, 13 May 2005 11:21:41 -0400
>
> The biggest problem I see is that interactive device one uses to view / edit
> that JCL. While a mod-5 terminal exist (to display 133 characters) the
> standard 27 lines or is it 24 lines is very limit
In <[EMAIL PROTECTED]>, on
05/13/2005
at 09:57 AM, "Low, David" <[EMAIL PROTECTED]> said:
>Is there, or has there been any requirement of increasing the 80 byte
>record limit of jcl? Reading the "PARM=" thread with interest, I can
>imagine having much longer jcl records would be a great thing
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Friday, May 13, 2005 10:22 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: 80 byte jcl record limit
>
>
> While the 80 character limit has a long history, I have
On 13 May 2005 06:06:09 -0700,
[EMAIL PROTECTED] (Chase, John) wrote:
>> -Original Message-
>> From: IBM Mainframe Discussion List On Behalf Of Taddei, Cathy
>>
>> I agree with Gil and Charles. IMO, a DD statement would be pointless.
>> If a programmer wanted to receive a parm via DD, th
While the 80 character limit has a long history, I have problems with the
idea to change the length of a JCL card for what might be a benefit. Not
having to learn how to code parameters that span more than one "card image".
The biggest problem I see is that interactive device one uses to view /
In a recent note, R.S. said:
> Date: Fri, 13 May 2005 14:49:53 +0200
>
> 256 bytes ?
> IMHO it is not worth to change from 100 to 256. Many "should be enough"
> limits occured much too short.
> BTW: I know *existing* OS/390 application using more than 256 bytes in
> PARM. It is c89 compil
In a recent note, EA MacNEIL said:
>
> Revolutionary changes in an evolutionary manner.
>
> Let's stretch PARMS and JCL Card Images, but not in such a way that we break
> some
> thing.
>
> I believe that a new zPARM is the better approach.
>
What would permitting longer PARM strings break? Ex
>>If that were true, none of my compile procs would
>>work (they all work just
>>fine, structured exactly as your example).
Just because we can do something, doesn't mean we should. Why do we have to
perform all of these unnatural acts, just because we are using archaic
constructs?
Peter Hunkeler wrote:
You won't see trailing blanks on the spool unless you have BLNKTRNC=YES
on the OUTCLASS(x) definition. JES2 truncates trailing blanks by default
(for line mode data).
and he of course meant to write
. . . unless you have BLNKTRNC=NO . . .
John Gilmore
Ashland, MA 01721
U.S.A.
In a recent note, Low, David said:
> Date: Fri, 13 May 2005 09:57:35 -0400
>
> Sorry if this is a stupid question...
>
Not at all.
> Is there, or has there been any requirement of increasing the 80 byte
> record limit of jcl? Reading the "PARM=" thread with interest, I can
>
Apparentl
>> In fact, PARM= is limited to 100 bytes. It can take more than 1 line of
>> JCL. So 80-byte limit for jobcards is not an issue in this context.
.
I totally disagree. Longer JCL cards would solve a lot of problems in
specifying PARMS that span records.
I have always hated the 80-byte car
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
>
> In a recent note, Chase, John said:
>
> > Date: Fri, 13 May 2005 08:05:55 -0500
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List On Behalf Of Taddei, Cathy
> >
Low, David wrote:
Sorry if this is a stupid question...
Is there, or has there been any requirement of increasing the 80 byte record limit of jcl? Reading the "PARM=" thread with interest, I can imagine having much longer jcl records would be a great thing if we suddenly have up to 65K of parm dat
In a recent note, Chase, John said:
> Date: Fri, 13 May 2005 08:05:55 -0500
>
> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf Of Taddei, Cathy
> >
> > I agree with Gil and Charles. IMO, a DD statement would be pointless.
>
Thanks for all the fish (but, n
Raymond,
That was my thought as well. It will not have a negative impact on older
programs, and will clearly require a change to both the called program, and
the caller.
Wayne Driscoll
Product Developer
Western Metal Supply
NOTE: All opinions are strictly my own.
-Original Message-
F
Sorry if this is a stupid question...
Is there, or has there been any requirement of increasing the 80 byte record
limit of jcl? Reading the "PARM=" thread with interest, I can imagine having
much longer jcl records would be a great thing if we suddenly have up to 65K of
parm data available.
On Thu, 2005-05-12 at 17:36 -0400, Peter Relson wrote:
> We all know and love (well, at least know) that the limitation
> in JCL for PARM= is 100 total characters. We are thinking (again)
> about expanding this, and would like to hear your thoughts.
Please also remember the START command processor
Well, without giving it much thought, would placing an unprintable
character, say high or low values, in the first byte of the PARM value to
indicate that the PARM was an XPARM, or PARMX, value work? Change the CI to
support it and only programs that know how to handle the extended PARM would
unde
On 12-May-2005, [EMAIL PROTECTED] (McKown, John) wrote:
> From what viewpoint? Remember that time is NOT universal according to
> Einstein and this has been validated by experiment. Therefore, to some
> observer, it is entirely possible that the Universe is only 6,000 years
> old. Say, somebody at
On Thu, 2005-05-12 at 20:44 -0700, Skip Robinson wrote:
> Let's just KISS: increase the allowable string length to 256. That should
> be plenty for any well-designed application.
"640K should be enough for anybody"
Seriously, we busted the 100 byte limitation a long time ago and had to
invent a h
Some of the potential problems an existing target routine might have
with an extended length parameter are
- It provided an area via DS of 100 characters, "knowing" that the
limit was 100, and then did an EX (execute) of an MVC to move the
parameter string, using the length in the halfword. Unfort
Hi,
Does any know if IBM sells hardware that you can use at the tape drive for
compression/encryption ? I found a few vendors that make such equipment but
they don't support Escon.
TIA
Dean
Dean Montevago
Sr. Systems Specialist
Visiting Nurse Service of New York
phone: (212) 609 - 5596
email:
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Taddei, Cathy
>
> I agree with Gil and Charles. IMO, a DD statement would be pointless.
> If a programmer wanted to receive a parm via DD, they could have done
> it already. One of the advantages of PARM= is that yo
Jay Maynard wrote:
On Fri, May 13, 2005 at 08:13:39AM -0400, Bob Shannon wrote:
Seriously, we're talking about a parameter. I agree that 256 bytes ought
to be sufficient.
Indeed. I can't recall where I read it, but someone suggested that program
designers avoid constraints that are powers of ten
on 5/13/05 7:13 AM, Bob Shannon at [EMAIL PROTECTED] wrote:
---SNIP
> Seriously, we're talking about a parameter. I agree that 256 bytes ought
> to be sufficient.
>
Bob,
I sort of agree with you BUT... I have gotten more JCL errors than at
any time w
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Miklos Szigetvari
>
> Hi
>
> I would vote for the DD solution.
> A reserved (maybe changeable) DD name for the long PARM's
That is already available. See, e.g., CICS:
//STEPNAME EXEC PGM=DFHSIP,PARM=(START=INITIAL
On Fri, May 13, 2005 at 08:13:39AM -0400, Bob Shannon wrote:
> Seriously, we're talking about a parameter. I agree that 256 bytes ought
> to be sufficient.
Indeed. I can't recall where I read it, but someone suggested that program
designers avoid constraints that are powers of ten, for they are
>Let's just KISS: increase the allowable string length to 256.
Sorry Skip, but it's too short. I want 16 exabytes. Pass all of the data
needed for the job via PARM=. This facility should fully support
zArchitecture. With outsourced labor on should be able to key in the
data cost effectively. I als
Skip Robinson wrote:
[snip]
Let's just KISS: increase the allowable string length to 256. That should
be plenty for any well-designed application.
[snip]
I would say 4K would be a better number. If you wanted to pass two path
names, an input and an output for instance, that would easily use up y
>> I seem to recall reading a document on a proposed re-write of device
>> allocation processing that would remove the serialization that makes
the
>> IEF238D message so damaging.
> This is being delivered in z/OS 1.7. I'm pretty sure it was discussed
at
> SHARE, but I don't remember attending suc
>As for blanks beyond that end of data, that could be
>legitimate if it isn't an artifact of SDSF; you'd need to see what the
>actual data on SPOOL are, which SDSF won't tell you.
You won't see trailing blanks on the spool unless you have BLNKTRNC=YES
on the OUTCLASS(x) definition. JES2 truncates
Hello Bruce,
the CHPID is dedicated to one lpar, so that the lpar number on windows is 0.
I have stopped the old os390 and then started zos with the same mpc and
ip-device configuration as os390 in the same lpar. The windows side is
completely unchanged. In our try-and-error-procedure have also s
>You can do it with an exit specified in MPFLSTxx member.
Forgot about this, indeed. Too long since I last worked on this
question, it seems.
Peter Hunkeler
Senior IT Specialist, IBM zSeries Technical Sales Support, Switzerland
---
On Thu, May 12, 2005 at 10:19:37PM -0400, Arthur T. ([EMAIL PROTECTED]) wrote:
[snip]
> OTOH, almost anything you do within JCL hits the
> problem of continuing the command across several card
> images. Perhaps if the XPARM pointed to a // PARM
> statement (like the // OUTPUT statement),
The BBC tell me they used it - or extracts of it - seven times.
It certainly went out on BBCÂ Radio Five Live at 16:09 on 5 May 2005, on
Radio 2 at 18:00 and Radio 4 at 21:00 - they also used it on two satellite
channels and I've had two emails from people in the USA who picked it up
from the BB
This is being delivered in z/OS 1.7. I'm pretty sure it was discussed at
SHARE, but I don't remember attending such a session.
.
.
.
JO.Skip Robinson
Southern California Edison Company
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]
IBM Mainframe Discussion
On Thu, 12 May 2005 18:18:30 -0700, Charles Mills <[EMAIL PROTECTED]> wrote:
>I am 100% with Gil on this.
>
Me too!
Clearly, Gil has given the matter already quite some thougth. His arguments
look very valid to me.
Cheers,
Jantje.
---
I seem to recall reading a document on a proposed re-write of device
allocation processing that would remove the serialization that makes the
IEF238D message so damaging.
If anyone can help find it for me I would much appreciate it.
Thanks in advance
Bruce Hewson
---
You can do it with an exit specified in MPFLSTxx member.
For example I have an exit (DCSAEXIT) which displays CSA usage if you enter
the command D CSA
The entry in MPFLST00 looks like this :
.CMD USEREXIT(DCSAEXIT)
Paul Beesley
UKOSG, EDS, Bournemouth
* 01202 502334
* 07790 495140
* [E
90 matches
Mail list logo
