Re: Of interest to the Independent Contractors on the list

[Gerhard Postpischil]

On 5/20/2010 2:18 PM, Greg Shirey wrote:

This type of error has been reported various times over the years - it
was around before the term Y2K was invented.


I suspect you're right, but I was trying to find the reporting of the
specific incident cited as happening "at the same time" in Fairfax
County (the "same time" being a period beginning 12/31/1999 and
ending 1/3/2000, unless I have misunderstood the post).  Perhaps the
"field day" the press had with the item was not archived for the
Internet.


You misinterpreted my "at the same time", which I intended to 
refer to the era of the Y2K "panic". While the error was not 
directly Y2K related, it had the same cause of using a two-digit 
year inappropriately. The only regular daily I was reading at 
the time was the Washington Post, which is where it would have 
appeared, although it also have been on the local TV news.



Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP Get Blocked by ISPF EDIT

[Hunkeler Peter (KIUP 4)]

>Would anyone care to submit a Requirement that ISPF defer 
>requesting the EXCL SPFEDIT until the first SAVE?  

I would vote against it. Definitely! If I'm in EDIT, I expect
that nothing can change the content under the covers, no matter
whether I'm going to actuially change the content or not.

Ed: How happy would you be if your automated ftp process 
successfully replaces the member someone else is editing at
the same time. A single SAVE and your successfull ftp isn't
worth a dime anymore.



--
Peter Hunkeler
Credit Suisse

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP Get Blocked by ISPF EDIT

[Hunkeler Peter (KIUP 4)]

>o Kudos to FTP server -- the messages are excellent.

Could only be topped if the message would the who the
holder was.

--
Peter Hunkeler
Credit Suisse

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Caution: Bad joke / pun?

[Hunkeler Peter (KIUP 4)]

>Why is text in IBM-1047 more stable that text in ISO8859-1?
>
>ISO8859-1 are basically ANSI characters.

>(ANSI --> antsy, just in case it is just too weird for some). 
>I know, if I have to explain it, it isn't really funny.

Not necessarily! If you're not a native speaker, like me,
you might simply not know the word "antsy". Thanks to your
hint, I was then able to enjoy your pun.

--
Peter Hunkeler
Credit Suisse

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: LINK Question (SRB Mode?)

[Chris Craddock]

On Thu, May 20, 2010 at 2:15 PM, Art Celestini wrote:

> A colleague has written me about a set of circumstances he is observing:
> Program “A” is authorized, running in Key 7, TCB mode, and issues a LINK
> for
> Program “B”.  When Program “B” gets control, it finds PSATOLD=0 and
> PSASRBM=04.  Program “A’s” state was verified with a S0C1 just before the
> LINK, and Program “B’s” state verified with a S0C1 at entry.
>
> How could LINK possibly give the target program control in SRB Mode?
>
> Offhand, I don’t know the z/OS release he is running on but I expect it
> would
> be at least 1.8.
>

First, let's be clear there is no possible connection whatsoever
between issuing a LINK macro and finding yourself running under an SRB. LINK
is a task-mode-only function and does not result in the transfer of control
to another unit of work. So just abandon that idea altogether. It isn't an
APAR-able IBM bug, or some alien conspiracy. I don't care what z/OS release
it is, I would guarantee sight unseen that it has NOTHING to do with a bug
in the dispatcher. The world as we know it would end if that were ever
true.

One of two things is true. First, assuming the SRB-mode condition is
accurately reported, then the only explanation is that some other unit of
work (directly or indirectly) scheduled Program B as an SRB. Any temporal
relationship to the LINK macro also being issued for Program B is
coincidental. The second (and I believe more likely) case is that the
environmental conditions are just not accurately being reported. Program B
is getting control under a new PRB in the same task that issued the LINK
just like it has since the beginning of time.

-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: rent system z

[Hank Oerlemans]

Come on now the planet is suffering.

You should take the green option. 

Recycle.

Hank



From:
Timothy Sipples/Chicago/i...@ibmus
To:
IBM-MAIN@bama.ua.edu
Date:
21/05/2010 02:34 PM
Subject:
Re: rent system z
Sent by:
IBM Mainframe Discussion List 



Ah, got it now.

That's similar to: "May I borrow a tissue?" Most people don't want used
tissues returned. :-)

- - - - -
Timothy Sipples
Resident Architect (Based in Singapore)
STG Value Creation and Complex Deals Team
IBM Growth Markets
E-Mail: timothy.sipp...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: rent system z

[Timothy Sipples]

Ah, got it now.

That's similar to: "May I borrow a tissue?" Most people don't want used
tissues returned. :-)

- - - - -
Timothy Sipples
Resident Architect (Based in Singapore)
STG Value Creation and Complex Deals Team
IBM Growth Markets
E-Mail: timothy.sipp...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: rent system z

[Joel C. Ewing]

On 05/19/2010 01:47 AM, Timothy Sipples wrote:
> Tony Harminc writes:
>> The biggest difficulty is returning the time when the rental
>> period is over. I suggest buying it outright...
> 
> I don't understand this comment, but maybe that's my fault? The System z
> Remote Development Program is a month-at-a-time rental. But the rental
> continues month-to-month (with your code and data undisturbed) unless you
> want to stop renting.
> 
> - - - - -
> Timothy Sipples
> Resident Architect (Based in Singapore)
> STG Value Creation and Complex Deals Team
> IBM Growth Markets
> E-Mail: timothy.sipp...@us.ibm.com
...
English Semantics.  That which you "rent/lease" must be returned to
owner at end of lease.  That which you "buy" does not.

You can rent/lease hardware and hardware resources, which gives you
access to the hardware; but execution time on hardware to which you
don't have access by ownership or lease can only be bought because there
is no way to return the time at end of lease.

The case you describe should be more accurately described as a rental of
hardware resources - for example DASD subsystem space for retaining your
data whether you are actively using it or not.  If a company providing
the kind of service described calls it "leasing of computer time", they
are abusing the English language.  I would be willing to bet that anyone
providing such services would charge based on the physical resources
used, not the clock hours in the lease duration or the clock hours your
applications are running.  It is the hardware resources that are rented,
not the "time".

Perhaps pedantic; but then programming itself is a very pedantic
exercise, where misuse of one "verb" in a program can cause total failure.
  Joel C Ewing

-- 
Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: LINK Question (SRB Mode?)

[Art Celestini]

Jim:

I forwarded your remarks but got nothing back about what the system trace
might or might not show.  I think it is probably the circumstances that 
Steve Thompson described.  (See my reply to him.)

Thanks,
Art


At 03:36 PM 5/20/2010, Jim Mulder wrote:
 

>  It couldn't.  System trace in a dump would show what actually
>happened.
>
>  Did something perhaps specify Program "B" as the ERRET
>on a cross memory POST? 
>
>Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY
>



==
Art Celestini   Celestini Development Services
Phone: 201-670-1674Wyckoff, NJ
=  http://celestini.com  =
Mail sent to the "From" address  used in this post
will be rejected by our server.   Please send off-
list email to:  ibmmaincelestinicom.
==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: LINK Question (SRB Mode?)

[Art Celestini]

Thanks, Steve.

I've suggested my colleague make a local copy of PSATOLD before the S0C1
in the target program.  That should tell him for sure whether he is really
in SRB Mode.

Art


At 03:41 PM 5/20/2010, Thompson, Steve wrote:
 

>I had asked this same question of Dump Services people. I will summarize
>what was said.
>
>Basically, when an sdump is being taken of your address space, the CPU
>it (SDUMP) is running on, is in SRB mode. If that was also the same CPU
>you were using, it may appear in the dump to have been in SRB mode, but
>when your program was running it may well have been running in TCB mode.
>
>IF PSATOLD is zero when your program checks it (while it is being
>dispatched), it is NOT in TCB mode. If this is not true, and you can
>otherwise prove you are in TCB mode, you have the opportunity to cause
>IBM to take an APAR (probably for a dispatcher bug).
>
>Regards,
>Steve Thompson



==
Art Celestini   Celestini Development Services
Phone: 201-670-1674Wyckoff, NJ
=  http://celestini.com  =
Mail sent to the "From" address  used in this post
will be rejected by our server.   Please send off-
list email to:  ibmmaincelestinicom.
==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Caution: Bad joke / pun?

[John McKown]

Why is text in IBM-1047 more stable that text in ISO8859-1?



ISO8859-1 are basically ANSI characters.





(ANSI --> antsy, just in case it is just too weird for some). I know, if
I have to explain it, it isn't really funny.


-- 
John McKown
Maranatha! <><

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Extracting BIND/Link-edit date from a program object or load module

[john gilmore]

I have not followed the [other] thread in which this topic is currently being 
talked about, and I do not understand the thrust of what is being said in that 
thread.
 
Let me therefore begin at the beginning.  The linkage editor and now, more 
generously, the binder have 'always' supported the use of IDENTIFY statements 
[which have nothing to do with the IDENTIFY macro].  These statements permit 
arbitrary information to be associated with a CSECT or RSECT in readily 
retrievable IDRs association with a load module or program object.  
 
IDENTIFY statements are used by ALL of the IBM compilers and assemblers I am 
familiar with and by both the linkage editor and the binder themselves to 
identify their versions and levels and provide a timestamp from which 
traditional date/time values can be obtained readily.
 
A program object stored in a PDSE that was assembled first by, say, version V.R 
of the HLASM and subsequently processed by version v.r of the binder to produce 
this program object will thus contain at least two IDRs, one requested by the 
assembler and another supplied by the binder, both of which identify these two 
programs and contain processing date-and-time information.
 
Discussions of whether or not such information should or should not be 
available in association with program objects or load modules are thus moot at 
best.  These timestamps are and have been readily available for decades.

 

In the unlikely situation that some non-IBM compiler or assembler does not 
provide such timestamps, users of this translator can themselves provide 
IDENTIFY statements that do so. 

John Gilmore Ashland, MA 01721-1817 USA



  
_
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: GDGs and use of SCRATCH and NOSCRATCH

[Frank Swarbrick]

Thanks to everyone for answering this question.  I was just experiencing
what must be the NOSCRATCH behavior.  Serendipity that this thread just
occured.

On 5/20/2010 at 2:18 PM, in message
<4bf59933.4010...@bremultibank.com.pl>,
"R.S."  wrote:
> W dniu 2010-05-20 22:01, Lizette Koehler pisze:
>> I am trying to understand the relationship between the use of
SCRATCH and 
> NOSCRATCH in an SMS environment with GDGs.
>>
>> According to the manual:
>>
>>   SCRATCH  - SPECIFIES THAT THE GENERATION DATA SET IS TO BE
REMOVED
>>  FROM THE VTOC OF THE VOLUME ON WHICH IT RESIDES WHEN IT
IS
>>  UNCATALOGED.
>>   NOSCRATCH
>>- SPECIFIES THAT THE GENERATION DATA SET IS NOT TO BE
>>  REMOVED FROM THE VTOC OF THE VOLUME ON WHICH IT
RESIDES
>>  WHEN IT IS UNCATALOGED.
>>
>> But an SMS environment should not allow a dataset to be
uncataloged.
>>
>> So, in an SMS environment, does it really matter if SCRATCH or
NOSCRATCH is 
> used?
> 
> Yes, it does. SCRATCH option causes the oldest generation to be
deleted 
> (I assume NOEMPTY, just to simplify).
> NOSCRATCH does not delete the oldest generation - the dataset will
stay 
> on DASD. However such dataset is no longer part of GDG. It is
cataloged, 
> but you cannot reference it using GDG.NAME(-n) relative name. It is
more 
> like regular nonVSAM dataset with GVyy as last qualifier.
Cataloged, 
> of course.
> 
> -- 
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> --
> BRE Bank SA
> ul. Senatorska 18
> 00-950 Warszawa
> www.brebank.pl 
> 
> Sąd Rejonowy dla m. st. Warszawy 
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
> nr rejestru przedsiębiorców KRS 025237
> NIP: 526-021-50-88
> Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w

> całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją

> warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały
XXI WZ z 
> dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października
2008r., 
> może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym
kapitale 
> zakładowym BRE Banku SA będą w całości opłacone.
> 
>
--
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

>>> 

The information contained in this electronic communication and any
document attached hereto or transmitted herewith is confidential and
intended for the exclusive use of the individual or entity named above. 
If the reader of this message is not the intended recipient or the
employee or agent responsible for delivering it to the intended
recipient, you are hereby notified that any examination, use,
dissemination, distribution or copying of this communication or any part
thereof is strictly prohibited.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and
destroy this communication.  Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SDSF and MQ

[Shmuel Metz (Seymour J.)]

In <46790b267a524cb4a29fe946d4146...@ericnbpc>, on 05/01/2010
   at 11:26 AM, Eric Bielefeld  said:

>I remember the shock when I left a JES2 shop in the mid 80's and went
>to a JES3 shop and I couldn't use SDSF.  The horror!  I had to use
>the ISPF output command.

SDSF is not the only SPOOL viewer. There are some that were
specifically written for JES3. I've even seen fans of those make
invidious comparisons of SDSF to them.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Amazing article.

[Shmuel Metz (Seymour J.)]

In
<4c5d185039a6a0499f76fa65ac606dbc0452d...@nct0010cp3mb04.ds.irsnet.gov>,
on 05/18/2010
   at 05:06 PM, Hylton Tom P  said:

>OS/2 is dead,

FSVO dead.

>so users were forced to migrate off.

Some were.

>Possibly some existing and "closed" applications are being in 
>use nowadays.

There's still application development.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Member name format for z/OS directory as simulated PDS?

[Shmuel Metz (Seymour J.)]

In
<6b34aedeeb35274e81437a445900b2d747f...@hdqsrvexcvs.ssfcuad.ssfcu.org>,
on 05/10/2010
   at 05:38 PM, "Ward, Mike S"  said:

>I know the word, but I have never seen it spelled that way. :)

The use of foo and bar as, e.g., variable names, goes back to the
hacker culture at MIT. And, yes, it derives from the acronym you're
thinking of.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP Get Blocked by ISPF EDIT

[Paul Gilmartin]

On Thu, 20 May 2010 17:20:49 -0700, Charles Mills wrote:

>> I believe that in this case FTP client either "re-allocat[ed] a
>> clone" or bypassed the allocation and used UNIX system calls to
>> access the related path.
>
>May be. Do you see allocation messages? Do you see any references to
>SYS1 or similar? (You might have to try from a batch job to make it
>clearer.)
>
I suspect it used UNIX system calls.  I'm dismayed that it ignored
the attributes on the DD statement; I'm indifferent about what it
did instead.

>I don't even know: if a regular old (let's say COBOL) program reads from a
>DD allocated to a zFS path with LRECL=40 in the DD, does it see 40-byte
>records?
>
Let's say IEBGENER.  It's been a while since I tried this,
but, yes, IEBGENER saw 40-byte records.  If anyone is skeptical,
I'll repeat the experiment.  If COBOL and IEBGENER behave
differently, I'll call one of them wrong.  Since FTP and IEBGENER
behave differently, I'm calling one of them wrong.  I blame FTP.
DD parameters should be respected.

(HFS; we're dragging our feet on z/FS.  If zFS and HFS behave
differently ...)

>-Original Message-
>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
>Of Paul Gilmartin
>
>allocate dd(putdd) filedata(binary) path('/etc/services') recfm(f) 
> lrecl(40) blksize(4000)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP Get Blocked by ISPF EDIT

[Charles Mills]

> I believe that in this case FTP client either "re-allocat[ed] a
> clone" or bypassed the allocation and used UNIX system calls to
> access the related path.

May be. Do you see allocation messages? Do you see any references to
SYS1 or similar? (You might have to try from a batch job to make it
clearer.)

I don't even know: if a regular old (let's say COBOL) program reads from a
DD allocated to a zFS path with LRECL=40 in the DD, does it see 40-byte
records?

Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Thursday, May 20, 2010 4:17 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: FTP Get Blocked by ISPF EDIT

On Thu, 20 May 2010 14:16:05 -0700, Charles Mills wrote:

>I believe FTP by DD name applies to both GETs and PUTs but only to the
>client end. You cannot do a PUT to or a GET from a DD name (only the
>converse). OTOH, I believe it does use the DD allocation rather than
>re-allocating a clone.
>
I just tried 

ALLOCATE DD(PUTDD) SHR DSN('SYS1.MACLIB(SPLEVEL)') LRECL(40)
FTP
...
PUT //DD:PUTDD ...
...

I stand corrected; the overriding DD attributes were honored
and the records were split into 40-character lines.

TRANSMIT is a horse of a different choler.  I tried:

TRANSMIT FOO.BAR FILE(PUTDD) OUTDSN(TEMP.FOOXMIT)

... and watched as IEBCOPY messages scrolled by for the unload
of the entire SYS1.MACLIB.  Wrong, wrong!  "Using Data Sets"
makes it very clear that when a data set name and member are
specified, the allocation is Physical Sequential.  TRANSMIT
ought to have simply OPENed a DCB for PUTDD and made an XMIT
package of whatever it found on a QSAM read.  IEBCOPY shouldn't
enter the picture.

(BTW, how can I interrupt IEBCOPY in this situation.  PA1
gave me a READY prompt, but when I pressed ENTER the IEBCOPY
messages resumed.  I finally resigned myself to pressing
ENTER until they finished scrolling by.)

Another experiment:

allocate dd(putdd) filedata(binary) path('/etc/services') recfm(f)
lrecl(40) blksize(4000)
FTP unixhost
...
QUOTE TYPE I
PUT //DD:PUTDD foolevel
...

I would have expected that QSAM reads from PUTDD would have
yielded 40-character records (some with internal NLs) and
the ASCII transfer by the client would convert to ASCII and
insert .  Instead, the original record structure was
preserved with a  inserted after each.  The allocation
parameters FILEDATA(BINARY) LRECL(40) were ignored:
...
# Network services, Internet style^M
#^M
echo7/tcp^M
echo7/udp^M
discard 9/tcp   sink null^M
discard 9/udp   sink null^M
systat  11/tcp  users^M
daytime 13/tcp^M
daytime 13/udp^M
...

I believe that in this case FTP client either "re-allocat[ed] a
clone" or bypassed the allocation and used UNIX system calls to
access the related path.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Getting "BIND/LINK" date out of load module members

[Paul Gilmartin]

On Thu, 20 May 2010 16:38:49 -0500, Rick Fochtman wrote:
>>
>>   [...]. Most of those other OSes have directories (i-nodes; whatever)
>>where such timestamp information is kept.
>>
>I don't regard it as a defect at all. The Operating System doesn't need
>this date information to function properly; why clutter things up with
>info that's not needed? Most applications also don't need it; it's only
>a convenience for us humans.
>
And until you explained this, I had believed that the Operating
System as a whole existed as a convenience for us humans; not, as
you appear to believe, merely to satisfy its own needs.

As for "clutter", better to do such things consistently, in DFSMS
for example, rather than haphazardly in ISPF, NFS server, and
whatever other services feel obliged to simulate ISPF's facility.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP Get Blocked by ISPF EDIT

[Paul Gilmartin]

On Thu, 20 May 2010 14:16:05 -0700, Charles Mills wrote:

>I believe FTP by DD name applies to both GETs and PUTs but only to the
>client end. You cannot do a PUT to or a GET from a DD name (only the
>converse). OTOH, I believe it does use the DD allocation rather than
>re-allocating a clone.
>
I just tried 

ALLOCATE DD(PUTDD) SHR DSN('SYS1.MACLIB(SPLEVEL)') LRECL(40)
FTP
...
PUT //DD:PUTDD ...
...

I stand corrected; the overriding DD attributes were honored
and the records were split into 40-character lines.

TRANSMIT is a horse of a different choler.  I tried:

TRANSMIT FOO.BAR FILE(PUTDD) OUTDSN(TEMP.FOOXMIT)

... and watched as IEBCOPY messages scrolled by for the unload
of the entire SYS1.MACLIB.  Wrong, wrong!  "Using Data Sets"
makes it very clear that when a data set name and member are
specified, the allocation is Physical Sequential.  TRANSMIT
ought to have simply OPENed a DCB for PUTDD and made an XMIT
package of whatever it found on a QSAM read.  IEBCOPY shouldn't
enter the picture.

(BTW, how can I interrupt IEBCOPY in this situation.  PA1
gave me a READY prompt, but when I pressed ENTER the IEBCOPY
messages resumed.  I finally resigned myself to pressing
ENTER until they finished scrolling by.)

Another experiment:

allocate dd(putdd) filedata(binary) path('/etc/services') recfm(f) 
lrecl(40) blksize(4000)
FTP unixhost
...
QUOTE TYPE I
PUT //DD:PUTDD foolevel
...

I would have expected that QSAM reads from PUTDD would have
yielded 40-character records (some with internal NLs) and
the ASCII transfer by the client would convert to ASCII and
insert .  Instead, the original record structure was
preserved with a  inserted after each.  The allocation
parameters FILEDATA(BINARY) LRECL(40) were ignored:
...
# Network services, Internet style^M
#^M
echo7/tcp^M
echo7/udp^M
discard 9/tcp   sink null^M
discard 9/udp   sink null^M
systat  11/tcp  users^M
daytime 13/tcp^M
daytime 13/udp^M
...

I believe that in this case FTP client either "re-allocat[ed] a
clone" or bypassed the allocation and used UNIX system calls to
access the related path.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Enterprise Extender, z/OS 1.11

[Brian Peterson]

I am pretty sure there was an incompatibility with EE across some number of
z/OS releases.  Your z/OS 1.4 system might NOT be able to connect to a new
z/OS 1.11 system via EE.  Last year, we almost had to delay our z/OS 1.10
implementation due to downlevel partnersas I recall.

I would open a PMR with IBM and ask the experts.

Brian

On Thu, 20 May 2010 19:05:50 +, Linda Mooney wrote:

>Greetings All, 
>
>We are currently running z/OS 1.4 (yeah, I know) and use Enterprise
Extender to conect with another data center.  The other data center plans
to cut over to z/OS 1.11 this summer.  Does Enterprise Extender still
function with 1.11? 
>
>TIA, 
>
>Linda Mooney 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Enterprise Extender, z/OS 1.11

[Linda Mooney]

Thanks Ron! 




- Original Message - 
From: "Ron Wells"  
To: IBM-MAIN@bama.ua.edu 
Sent: Thursday, May 20, 2010 12:48:08 PM GMT -08:00 US/Canada Pacific 
Subject: Re: Enterprise Extender, z/OS 1.11 

should be fine...ran 1.7 to 1.9 and 1.11 (that rel we had lots of hmc 
maint..no problem...outside customers was running ahead of us at 
time..EE..no problem..REAL STUFF.lol 



From:   Linda Mooney  
To:     IBM-MAIN@bama.ua.edu 
Date:   05/20/2010 02:41 PM 
Subject:        Re: Enterprise Extender, z/OS 1.11 
Sent by:        IBM Mainframe Discussion List  



Hi Ron, 



Does either system require any service?   



Thanks, 



Linda 


- Original Message - 
From: "Ron Wells"  
To: IBM-MAIN@bama.ua.edu 
Sent: Thursday, May 20, 2010 12:26:49 PM GMT -08:00 US/Canada Pacific 
Subject: Re: Enterprise Extender, z/OS 1.11 

yep 



From:   Linda Mooney  
To:     IBM-MAIN@bama.ua.edu 
Date:   05/20/2010 02:05 PM 
Subject:        Enterprise Extender, z/OS 1.11 
Sent by:        IBM Mainframe Discussion List  



Greetings All, 



We are currently running z/OS 1.4 (yeah, I know) and use Enterprise 
Extender to conect with another data center.  The other data center plans 
to cut over to z/OS 1.11 this summer.  Does Enterprise Extender still 
function with 1.11? 



TIA, 



Linda Mooney 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO 
Search the archives at http://bama.ua.edu/archives/ibm-main.html 

-- 
Email Disclaimer 
This  E-mail  contains  confidential  information  belonging to the 
sender, which  may be legally privileged information.  This information is 
intended only  for  the use of the individual or entity addressed above. 
 If you are not  the  intended  recipient, or  an  employee  or  agent 
responsible for delivering it to the intended recipient, you are hereby 
notified that any disclosure,  copying, distribution, or the taking of any 
action in reliance on the contents of the E-mail or attached files is 
strictly prohibited. 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO 
Search the archives at http://bama.ua.edu/archives/ibm-main.html 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO 
Search the archives at http://bama.ua.edu/archives/ibm-main.html 

-- 
Email Disclaimer 
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited. 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO 
Search the archives at http://bama.ua.edu/archives/ibm-main.html 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Getting "BIND/LINK" date out of load module members

[Rick Fochtman]

-
I'll regard this as a defect in z/OS.

Pedantic. Most of those other OSes have directories (i-nodes; whatever) 
where such timestamp information is kept.


So much the worse for z/OS. And why wasn't this enhancement provided 
with the advent of PDSE? (Or was it?)


Did I hear someone say Requirement? Does the expression "snowflake in 
Hell" come to mind? Suppose that STOW were enhanced to save timestamp 
information in the same format as ISPF (but GMT would be better). What 
compatibility problems would arise with applications that employ the 
user info in the directory for other purposes. And even, what unexpected 
directory space overflows would occur?


I don't regard it as a defect at all. The Operating System doesn't need 
this date information to function properly; why clutter things up with 
info that's not needed? Most applications also don't need it; it's only 
a convenience for us humans. And I wouldn't like to try to rewrite 
Program Fetch, considering all the formats of data that are already in 
the directory for a load module.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP Get Blocked by ISPF EDIT

[Charles Mills]

I believe FTP by DD name applies to both GETs and PUTs but only to the
client end. You cannot do a PUT to or a GET from a DD name (only the
converse). OTOH, I believe it does use the DD allocation rather than
re-allocating a clone.

Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Thursday, May 20, 2010 10:40 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: FTP Get Blocked by ISPF EDIT

On Thu, 20 May 2010 20:26:57 +0300, Binyamin Dissen wrote:

>On Thu, 20 May 2010 09:44:07 -0700 Edward Jaffe wrote:
>
>:>Did you know that z/OS ftp GET is blocked by ISPF EDIT?  =-O
>
>:>ftp> cd 'sys2.mvsmods.cntl'
>:>ftp> get istinclm istinclm.jcltxt
>
>Wouldn't the DDNAME approach work?
>
No, because I believe the OP was trying a GET from a remote
client.  DDNAME is available only for a PUT from a local client.

And, dismayingly, I have empirical evidence that FTP server
does not read from/write to the DDNAME in the put/get
command.  Rather it seems to ferret out the DSNAME or
PATH from the TIOT (JFCB? whatever), and reallocate.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ZAAPAWMT under Hiperdispatch

[Graham Harris]

Allan Staller said:
>>See OA31072..

Thanks Allan, that looks like a relatively new one, although doesnt look
like it applies in our environment.

John Eels said:
>>Do you have Honor Priority turned on (IFAHONORPRIORITY=YES) in IEAOPTxx,
or off (IFAHONORPRIORITY=NO)?

We have this set to YES, and thus expect to have the 'needs help' behaviour
taking place, but our GPs are being just a little too 'helpful'


I have had another off-list response, which confirms that upping the
ZAAPAWMT value is potentially appropriate in our situation, and so I will
look to getting this increased, and assessing the impact.

Thanks.



On 20 May 2010 13:40, Staller, Allan  wrote:

> See OA31072..
>
> 
> In our development environment, we have dozens of Websphere App servers
> running, and we only have one zAAP (on a z10-704).
>
> The aggravation is that we have significant overflow of zAAP eligible
> workload to GP engines, despite the zAAP being nowhere near 100% busy
> (whereas all the GPs are 100% busy, pretty much 24x7! with a slight
> respite
> at weekends.).
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Of interest to the Independent Contractors on the list

[Clark Morris]

On 20 May 2010 09:55:47 -0700, in bit.listserv.ibm-main you wrote:

>--
>
>>> Countless other professionals did corresponding good work and as a
>>> direct consequence "Y2K" was not a disaster at all. One suspects that
>>> sections of the media were hoping it was going to be very bad (planes
>>> falling from the sky, toasters electrocuting their owners, elevators
>>> plummeting and countless other pieces of mundane equipment going
>>> Disney-dancing cranky.
>>
>>
>> At the time I was working for an ISV, and beginning 12/31/1999 all 
>> technical employees were "on call", and three at a time had to man the 
>> help line until 1/3. We got a few calls, but mostly minor stuff. 
>> However, at the same time the Fairfax County, Virginia government 
>> wasn't doing so well - they sent notice of a fine to the parents of 
>> someone for failing to register their four-year old for kindergarten; 
>> unfortunately for them the press had a field day because the four-year 
>> old was really a 104 year-old man.
>
>--
>Leave us not forget the one poor guy in Europe (I think it was somewhere 
>in Italy) who got his 30-day jail sentence extended to 100 years + 30 days.
>
>Or the panic about all the computers in our cars suddenly failing. 
>(IIRC, there were 27 separate "computers" in a new Cadillac at the time.)

On the other hand the maintenance computer in the newest fire engine
in Bridgetown that checked to make sure that the maintenance was
performed would have prevented the fire engine from starting.  Since
many on the volunteer Fire Department worked for the local car
dealership, they would have known how to bypass the problem.  A fix
was sent by the manufacturer prior to 2000.  I got this from the town
administrator.  There also was a problem with a couple of the
computers on one oil company's newest super tankers as reported to the
Y2K office of that company.

>
>All prime examples of media know-nothings trying to be "know it alls". 
>Has anyone yet developed a vaccine for "stupid" ??  :-)
>
>Rick
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: GDGs and use of SCRATCH and NOSCRATCH

[R.S.]

W dniu 2010-05-20 22:01, Lizette Koehler pisze:

I am trying to understand the relationship between the use of SCRATCH and 
NOSCRATCH in an SMS environment with GDGs.

According to the manual:

  SCRATCH  - SPECIFIES THAT THE GENERATION DATA SET IS TO BE REMOVED
 FROM THE VTOC OF THE VOLUME ON WHICH IT RESIDES WHEN IT IS
 UNCATALOGED.
  NOSCRATCH
   - SPECIFIES THAT THE GENERATION DATA SET IS NOT TO BE
 REMOVED FROM THE VTOC OF THE VOLUME ON WHICH IT RESIDES
 WHEN IT IS UNCATALOGED.

But an SMS environment should not allow a dataset to be uncataloged.

So, in an SMS environment, does it really matter if SCRATCH or NOSCRATCH is 
used?


Yes, it does. SCRATCH option causes the oldest generation to be deleted 
(I assume NOEMPTY, just to simplify).
NOSCRATCH does not delete the oldest generation - the dataset will stay 
on DASD. However such dataset is no longer part of GDG. It is cataloged, 
but you cannot reference it using GDG.NAME(-n) relative name. It is more 
like regular nonVSAM dataset with GVyy as last qualifier. Cataloged, 
of course.


--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: GDGs and use of SCRATCH and NOSCRATCH

[Mueller, David]

We have always used SCRATCH for DASD-based GDGs (both SMS and non-SMS)
and NOSCRATCH for tape-based GDGs (since the tape-retention-system takes
care of expiration, so SCRATCH has no meaning and could confuse
someone). 

David Mueller | Systems Programmer 
SSRC (Southwood Shared Resource Center) 
2585 Shumard Oak Blvd, Suite 107 / Room 110  
Phone: 850-414-9134 || Fax: 850-921-8343 
E-mail: david.muel...@ssrc.myflorida.com 
  
Please Note: Florida has a very broad public records law. Most written
communications to or from state officials regarding state business are
public records available to the public and media upon request. Your
e-mail communications may therefore be subject to public disclosure. 


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Starr, Alan
Sent: Thursday, May 20, 2010 4:09 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: GDGs and use of SCRATCH and NOSCRATCH

Lizette,

I pulled this out of "Using Datasets". Hope it clarifies:

If you specify the NOSCRATCH parameter, the rolled off generation data
set is recataloged as rolled off and is disassociated with its GDG.

Cheers,
Alan 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Lizette Koehler
Sent: Thursday, May 20, 2010 13:02
To: IBM-MAIN@bama.ua.edu
Subject: GDGs and use of SCRATCH and NOSCRATCH

I am trying to understand the relationship between the use of SCRATCH
and NOSCRATCH in an SMS environment with GDGs.

According to the manual: 
  
 SCRATCH  - SPECIFIES THAT THE GENERATION DATA SET IS TO BE REMOVED

FROM THE VTOC OF THE VOLUME ON WHICH IT RESIDES WHEN IT IS

UNCATALOGED.

 NOSCRATCH

  - SPECIFIES THAT THE GENERATION DATA SET IS NOT TO BE

REMOVED FROM THE VTOC OF THE VOLUME ON WHICH IT RESIDES

WHEN IT IS UNCATALOGED.  

But an SMS environment should not allow a dataset to be uncataloged.

So, in an SMS environment, does it really matter if SCRATCH or NOSCRATCH
is used?

If the GDG is tape rather than DASD.  Does it really matter if SCRATCH
or NOSCRATCH is used.

Thanks

Lizette


--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: GDGs and use of SCRATCH and NOSCRATCH

[Starr, Alan]

Lizette,

I pulled this out of "Using Datasets". Hope it clarifies:

If you specify the NOSCRATCH parameter, the rolled off generation data set is 
recataloged as rolled off and is disassociated with its GDG.

Cheers,
Alan 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Lizette Koehler
Sent: Thursday, May 20, 2010 13:02
To: IBM-MAIN@bama.ua.edu
Subject: GDGs and use of SCRATCH and NOSCRATCH

I am trying to understand the relationship between the use of SCRATCH and 
NOSCRATCH in an SMS environment with GDGs.

According to the manual: 
  
 SCRATCH  - SPECIFIES THAT THE GENERATION DATA SET IS TO BE REMOVED  
FROM THE VTOC OF THE VOLUME ON WHICH IT RESIDES WHEN IT IS   
UNCATALOGED. 
 NOSCRATCH   
  - SPECIFIES THAT THE GENERATION DATA SET IS NOT TO BE  
REMOVED FROM THE VTOC OF THE VOLUME ON WHICH IT RESIDES  
WHEN IT IS UNCATALOGED.  

But an SMS environment should not allow a dataset to be uncataloged.

So, in an SMS environment, does it really matter if SCRATCH or NOSCRATCH is 
used?

If the GDG is tape rather than DASD.  Does it really matter if SCRATCH or 
NOSCRATCH is used.

Thanks

Lizette


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

GDGs and use of SCRATCH and NOSCRATCH

[Lizette Koehler]

I am trying to understand the relationship between the use of SCRATCH and 
NOSCRATCH in an SMS environment with GDGs.

According to the manual: 
  
 SCRATCH  - SPECIFIES THAT THE GENERATION DATA SET IS TO BE REMOVED  
FROM THE VTOC OF THE VOLUME ON WHICH IT RESIDES WHEN IT IS   
UNCATALOGED. 
 NOSCRATCH   
  - SPECIFIES THAT THE GENERATION DATA SET IS NOT TO BE  
REMOVED FROM THE VTOC OF THE VOLUME ON WHICH IT RESIDES  
WHEN IT IS UNCATALOGED.  

But an SMS environment should not allow a dataset to be uncataloged.

So, in an SMS environment, does it really matter if SCRATCH or NOSCRATCH is 
used?

If the GDG is tape rather than DASD.  Does it really matter if SCRATCH or 
NOSCRATCH is used.

Thanks

Lizette


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Getting "BIND/LINK" date out of load module members

[Sam Siegel]

On Thu, May 20, 2010 at 7:57 PM, J R  wrote:
>> Pedantic.  ...  GMT would be better ...
>
> Since you're being pedantic, wouldn't UTC be better?  ;-)
>
>
>
>> Date: Thu, 20 May 2010 13:16:27 -0500
>> From: paulgboul...@aim.com
>> Subject: Re: Getting "BIND/LINK" date out of load module members
>> To: IBM-MAIN@bama.ua.edu
>>
>> On Thu, 20 May 2010 14:03:48 -0400, Tony Harminc wrote:
>>
>> >On 20 May 2010 04:14, Frank Swarbrick wrote:
>> >> Yeah, I remembered that after I wrote the message.  But honestly, that is 
>> >> even worse.  PDS should have this information.  Every other OS I know of 
>> >> at least has last update date, if not both date/time and sometimes also 
>> >> creation date or date/time.
>> >
>> >Every other OS I know doesn't have PDSs.
>> >
>> I'll regard this as a defect in z/OS.
>>
>> Pedantic. Most of those other OSes have directories (i-nodes;
>> whatever) where such timestamp information is kept.

other platforms (windows, unix) have utilities (touch and the like)
that can update the external directory date and time stamp very
easily.  This is used quite often in the build process for force
unmodified code to be recompiled or relinked.  In this case, the
external timestamp does not reflect the actual link timestamp.

It would seem to be counter to the OPs requirement.

Also, in the case of composite links any external timestamp reflects
the status of the overall module and not necessarily any particular
component.  This is probably not relevant to the OPs requirements.

Externally maintained date and time stamps of any nature fall prey to
these type of utilities.


>>
>> So much the worse for z/OS. And why wasn't this enhancement provided
>> with the advent of PDSE? (Or was it?)
>>
>> Did I hear someone say Requirement? Does the expression "snowflake
>> in Hell" come to mind? Suppose that STOW were enhanced to save
>> timestamp information in the same format as ISPF (but GMT would
>> be better). What compatibility problems would arise with applications
>> that employ the user info in the directory for other purposes. And
>> even, what unexpected directory space overflows would occur?
>>
>> -- gil
>
> _
> Hotmail is redefining busy with tools for the New Busy. Get more from your 
> inbox.
> http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Enterprise Extender, z/OS 1.11

[Ron Wells]

should be fine...ran 1.7 to 1.9 and 1.11 (that rel we had lots of hmc 
maint..no problem...outside customers was running ahead of us at 
time..EE..no problem..REAL STUFF.lol



From:   Linda Mooney 
To: IBM-MAIN@bama.ua.edu
Date:   05/20/2010 02:41 PM
Subject:Re: Enterprise Extender, z/OS 1.11
Sent by:IBM Mainframe Discussion List 



Hi Ron, 



Does either system require any service?  



Thanks, 



Linda 


- Original Message - 
From: "Ron Wells"  
To: IBM-MAIN@bama.ua.edu 
Sent: Thursday, May 20, 2010 12:26:49 PM GMT -08:00 US/Canada Pacific 
Subject: Re: Enterprise Extender, z/OS 1.11 

yep 



From:   Linda Mooney  
To: IBM-MAIN@bama.ua.edu 
Date:   05/20/2010 02:05 PM 
Subject:Enterprise Extender, z/OS 1.11 
Sent by:IBM Mainframe Discussion List  



Greetings All, 



We are currently running z/OS 1.4 (yeah, I know) and use Enterprise 
Extender to conect with another data center.  The other data center plans 
to cut over to z/OS 1.11 this summer.  Does Enterprise Extender still 
function with 1.11? 



TIA, 



Linda Mooney 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO 
Search the archives at http://bama.ua.edu/archives/ibm-main.html 

-- 
Email Disclaimer 
This  E-mail  contains  confidential  information  belonging to the 
sender, which  may be legally privileged information.  This information is 
intended only  for  the use of the individual or entity addressed above. 
 If you are not  the  intended  recipient, or  an  employee  or  agent 
responsible for delivering it to the intended recipient, you are hereby 
notified that any disclosure,  copying, distribution, or the taking of any 
action in reliance on the contents of the E-mail or attached files is 
strictly prohibited. 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO 
Search the archives at http://bama.ua.edu/archives/ibm-main.html 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Enterprise Extender, z/OS 1.11

[Linda Mooney]

Hi Ron, 



Does either system require any service?  



Thanks, 



Linda 


- Original Message - 
From: "Ron Wells"  
To: IBM-MAIN@bama.ua.edu 
Sent: Thursday, May 20, 2010 12:26:49 PM GMT -08:00 US/Canada Pacific 
Subject: Re: Enterprise Extender, z/OS 1.11 

yep 



From:   Linda Mooney  
To:     IBM-MAIN@bama.ua.edu 
Date:   05/20/2010 02:05 PM 
Subject:        Enterprise Extender, z/OS 1.11 
Sent by:        IBM Mainframe Discussion List  



Greetings All, 



We are currently running z/OS 1.4 (yeah, I know) and use Enterprise 
Extender to conect with another data center.  The other data center plans 
to cut over to z/OS 1.11 this summer.  Does Enterprise Extender still 
function with 1.11? 



TIA, 



Linda Mooney 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO 
Search the archives at http://bama.ua.edu/archives/ibm-main.html 

-- 
Email Disclaimer 
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited. 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO 
Search the archives at http://bama.ua.edu/archives/ibm-main.html 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: LINK Question (SRB Mode?)

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Art Celestini
Sent: Thursday, May 20, 2010 2:16 PM
To: IBM-MAIN@bama.ua.edu
Subject: LINK Question (SRB Mode?)

A colleague has written me about a set of circumstances he is observing:

Program "A" is authorized, running in Key 7, TCB mode, and issues a LINK
for 
Program "B".  When Program "B" gets control, it finds PSATOLD=0 and 
PSASRBM=04.  Program "A's" state was verified with a S0C1 just before
the 
LINK, and Program "B's" state verified with a S0C1 at entry.  

How could LINK possibly give the target program control in SRB Mode?

Offhand, I don't know the z/OS release he is running on but I expect it
would 
be at least 1.8. 



I had asked this same question of Dump Services people. I will summarize
what was said.

Basically, when an sdump is being taken of your address space, the CPU
it (SDUMP) is running on, is in SRB mode. If that was also the same CPU
you were using, it may appear in the dump to have been in SRB mode, but
when your program was running it may well have been running in TCB mode.

IF PSATOLD is zero when your program checks it (while it is being
dispatched), it is NOT in TCB mode. If this is not true, and you can
otherwise prove you are in TCB mode, you have the opportunity to cause
IBM to take an APAR (probably for a dispatcher bug).

Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: LINK Question (SRB Mode?)

[Jim Mulder]

IBM Mainframe Discussion List  wrote on 05/20/2010 
03:15:57 PM:

> A colleague has written me about a set of circumstances he is observing: 
 
> Program ?A? is authorized, running in Key 7, TCB mode, and issues a LINK 
for 
> Program ?B?.  When Program ?B? gets control, it finds PSATOLD=0 and 
> PSASRBM=04.  Program ?A?s? state was verified with a S0C1 just before 
the 
> LINK, and Program ?B?s? state verified with a S0C1 at entry. 
> 
> How could LINK possibly give the target program control in SRB Mode?

  It couldn't.  System trace in a dump would show what actually
happened.

  Did something perhaps specify Program "B" as the ERRET
on a cross memory POST? 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Enterprise Extender, z/OS 1.11

[Ron Wells]

yep



From:   Linda Mooney 
To: IBM-MAIN@bama.ua.edu
Date:   05/20/2010 02:05 PM
Subject:Enterprise Extender, z/OS 1.11
Sent by:IBM Mainframe Discussion List 



Greetings All, 



We are currently running z/OS 1.4 (yeah, I know) and use Enterprise 
Extender to conect with another data center.  The other data center plans 
to cut over to z/OS 1.11 this summer.  Does Enterprise Extender still 
function with 1.11? 



TIA, 



Linda Mooney 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

LINK Question (SRB Mode?)

[Art Celestini]

A colleague has written me about a set of circumstances he is observing:  
Program “A” is authorized, running in Key 7, TCB mode, and issues a LINK for 
Program “B”.  When Program “B” gets control, it finds PSATOLD=0 and 
PSASRBM=04.  Program “A’s” state was verified with a S0C1 just before the 
LINK, and Program “B’s” state verified with a S0C1 at entry.  

How could LINK possibly give the target program control in SRB Mode?

Offhand, I don’t know the z/OS release he is running on but I expect it would 
be at least 1.8. 



==
Art Celestini   Celestini Development Services
Phone: 201-670-1674Wyckoff, NJ
=  http://celestini.com  =
Mail sent to the "From" address  used in this post
will be rejected by our server.   Please send off-
list email to:  ibmmaincelestinicom.
==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Enterprise Extender, z/OS 1.11

[Linda Mooney]

Greetings All, 



We are currently running z/OS 1.4 (yeah, I know) and use Enterprise Extender to 
conect with another data center.  The other data center plans to cut over to 
z/OS 1.11 this summer.  Does Enterprise Extender still function with 1.11? 



TIA, 



Linda Mooney 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Getting "BIND/LINK" date out of load module members

[J R]

> Pedantic.  ...  GMT would be better ...  

Since you're being pedantic, wouldn't UTC be better?  ;-)  


 
> Date: Thu, 20 May 2010 13:16:27 -0500
> From: paulgboul...@aim.com
> Subject: Re: Getting "BIND/LINK" date out of load module members
> To: IBM-MAIN@bama.ua.edu
> 
> On Thu, 20 May 2010 14:03:48 -0400, Tony Harminc wrote:
> 
> >On 20 May 2010 04:14, Frank Swarbrick wrote:
> >> Yeah, I remembered that after I wrote the message.  But honestly, that is 
> >> even worse.  PDS should have this information.  Every other OS I know of 
> >> at least has last update date, if not both date/time and sometimes also 
> >> creation date or date/time.
> >
> >Every other OS I know doesn't have PDSs.
> >
> I'll regard this as a defect in z/OS.
> 
> Pedantic. Most of those other OSes have directories (i-nodes;
> whatever) where such timestamp information is kept.
> 
> So much the worse for z/OS. And why wasn't this enhancement provided
> with the advent of PDSE? (Or was it?)
> 
> Did I hear someone say Requirement? Does the expression "snowflake
> in Hell" come to mind? Suppose that STOW were enhanced to save
> timestamp information in the same format as ISPF (but GMT would
> be better). What compatibility problems would arise with applications
> that employ the user info in the directory for other purposes. And
> even, what unexpected directory space overflows would occur?
> 
> -- gil
  
_
Hotmail is redefining busy with tools for the New Busy. Get more from your 
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Of interest to the Independent Contractors on the list

[Greg Shirey]

>From: IBM Mainframe Discussion List On Behalf Of Howard Brazee
>Sent: Thursday, May 20, 2010 11:16 AM

>This type of error has been reported various times over the years - it
>was around before the term Y2K was invented.

I suspect you're right, but I was trying to find the reporting of the  
specific incident cited as happening "at the same time" in Fairfax
County (the "same time" being a period beginning 12/31/1999 and  
ending 1/3/2000, unless I have misunderstood the post).  Perhaps the
"field day" the press had with the item was not archived for the
Internet. 

Greg   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Of interest to the Independent Contractors on the list

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman
> 
> --
> 
> 
> All prime examples of media know-nothings trying to be "know it alls".
> Has anyone yet developed a vaccine for "stupid" ??  :-)

The only one I know of works well but is always fatal.  :-)

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Getting "BIND/LINK" date out of load module members

[Paul Gilmartin]

On Thu, 20 May 2010 14:03:48 -0400, Tony Harminc wrote:

>On 20 May 2010 04:14, Frank Swarbrick wrote:
>> Yeah, I remembered that after I wrote the message.  But honestly, that is 
>> even worse.  PDS should have this information.  Every other OS I know of at 
>> least has last update date, if not both date/time and sometimes also 
>> creation date or date/time.
>
>Every other OS I know doesn't have PDSs.
>
I'll regard this as a defect in z/OS.

Pedantic.  Most of those other OSes have directories (i-nodes;
whatever) where such timestamp information is kept.

So much the worse for z/OS.  And why wasn't this enhancement provided
with the advent of PDSE?  (Or was it?)

Did I hear someone say Requirement?  Does the expression "snowflake
in Hell" come to mind?  Suppose that STOW were enhanced to save
timestamp information in the same format as ISPF (but GMT would
be better).  What compatibility problems would arise with applications
that employ the user info in the directory for other purposes.  And
even, what unexpected directory space overflows would occur?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP Get Blocked by ISPF EDIT

[Paul Gilmartin]

On Thu, 20 May 2010 09:44:07 -0700, Edward Jaffe wrote:
>
>125-FTP Server unable to obtain SHARED use of
>SYS2.MVSMODS.CNTL(ISTINCLM) which
>is held by: 008F EDJXADM  EXCL on SPFEDIT
>125 Data set SYS2.MVSMODS.CNTL(ISTINCLM) is not available
>550 SYS2.MVSMODS.CNTL(ISTINCLM) used exclusively by someone else.
>ftp> bye
>221 Quit command received. Goodbye.
>
BTW:

o Kudos to FTP server -- the messages are excellent.  (Or is this
  only because I have a deeper understanding of MVS protocols than
  I often care to admit?)

o Solaris client (but not OS X client) drops the connection when
  this occurs:

550 DATA.SET.NAME(FOO) used exclusively by someone else.
226 Abort successful.
ftp> pwd
421 Service not available, remote server has closed connection

  WTF???

o The message from MIM to the ISPF EDIT session is bizarre:

MIM1098I Contention with MVSNFS needs EXCL on 3MVS CN(INTERNAL)
MIM1099I USER holds SPFEDIT DATA.SET.NAME(FOO) EXCL CN(INTERNAL)

  Who let MVSNFS in the game?  Is it because I tried an NFS transfer
  much earlier and MIM hasn't forgotten?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Getting "BIND/LINK" date out of load module members

[Tony Harminc]

On 20 May 2010 04:14, Frank Swarbrick  wrote:
> Yeah, I remembered that after I wrote the message.  But honestly, that is 
> even worse.  PDS should have this information.  Every other OS I know of at 
> least has last update date, if not both date/time and sometimes also creation 
> date or date/time.

Every other OS I know doesn't have PDSs.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Getting "BIND/LINK" date out of load module members

[Frank Swarbrick]

>>> On 5/20/2010 at 2:22 AM, in message
<29s9v5lniuvtpalf97r7chtu7ogfmj7...@4ax.com>, Binyamin Dissen
 wrote:
> On Thu, 20 May 2010 02:14:33 -0600 Frank Swarbrick
>  wrote:
> 
> :>Yeah, I remembered that after I wrote the message.  But honestly, that is 
> even worse.  PDS should have this information.  Every other OS I know of at 
> least has last update date, if not both date/time and sometimes also creation 
> date or date/time.
> 
> Submit a requirement. 

No doubt.  I'm just amazed that such a requirement wasn't submited 30 years ago.

Frank

-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP Get Blocked by ISPF EDIT

[Paul Gilmartin]

On Thu, 20 May 2010 20:26:57 +0300, Binyamin Dissen wrote:

>On Thu, 20 May 2010 09:44:07 -0700 Edward Jaffe wrote:
>
>:>Did you know that z/OS ftp GET is blocked by ISPF EDIT?  =-O
>
>:>ftp> cd 'sys2.mvsmods.cntl'
>:>ftp> get istinclm istinclm.jcltxt
>
>Wouldn't the DDNAME approach work?
>
No, because I believe the OP was trying a GET from a remote
client.  DDNAME is available only for a PUT from a local client.

And, dismayingly, I have empirical evidence that FTP server
does not read from/write to the DDNAME in the put/get
command.  Rather it seems to ferret out the DSNAME or
PATH from the TIOT (JFCB? whatever), and reallocate.
For example, if I allocate with overriding DCB attributes
and do "FTP ... PUT //DD:...", the attributes used are
from the DSCB/label, not from my allocation.

(Or, am I thinking of TSO TRANSMIT?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Dynamic change of link address

[Bruce Schaefer]

We have many CNTLUNIT macros defined with 8 paths, similar to:
  CNTLUNIT CUNUMBR=6F00,PATH=((CSS(0),33,73,2E,3A,53,83,5A,3E)),*
UNITADD=((00,256)), *
LINK=((CSS(0),7120,7220,7320,7420,7124,7224,7324,7424)),*
CUADD=0,UNIT=2107
  IODEVICE ADDRESS=(6000,064),CUNUMBR=
(6F00),STADET=Y,UNIT=3390B
  IODEVICE ADDRESS=(6040,192),CUNUMBR=
(6F00),STADET=Y,UNIT=3390A

The above is repeated for CUADD=1 to F to define the entire 6000-6FFF 
device range.

If we change the 71xx link addresses to 77xx (and CF CHP(33,53)
OFFLINE on all LPARs on this machine), will the ACTIVATE IODF= 
command succeed?

My recollection tells me that the command will try to DELETE the CU, 
thus all devices would need to be offline. Is this correct or will the 
activate delete the affected paths, then readd with updated link 
addresses?

Thanks,
Bruce

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP Get Blocked by ISPF EDIT

[Paul Gilmartin]

On Thu, 20 May 2010 11:50:43 -0500, McKown, John wrote:

>> -Original Message-
>> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe
>>
>> Did you know that z/OS ftp GET is blocked by ISPF EDIT?  =-O
>>
>> This is a little scary since we use ftp all over the place in our
>> automated processes!
>>
>> ftp> get istinclm istinclm.jcltxt
>> 125-FTP Server unable to obtain SHARED use of
>> SYS2.MVSMODS.CNTL(ISTINCLM) which
>> is held by: 008F EDJXADM  EXCL on SPFEDIT
>
I don't know that I feel too bad about this.  I can rationalize it
as due prudence.  Suppose:

ISPF user does:
EDIT; change a few lines; SAVE

FTP user attempts:
GET, but member is in an invalid state.

ISPF user does:
Change some more lines; END
(Only now is content of member valid.)

This is safe only if ISPF user never SAVEs until all changes are made,
and FTP server has no way to determine this.

>Yeap, I've run into that a number of time. Editting a JCL member, do a SAVE, 
>then want to ftp it to my desktop. the ftp fails.
>
The behavior is the same even before the SAVE, by experiment.  Would
anyone care to submit a Requirement that ISPF defer requesting the
EXCL SPFEDIT until the first SAVE?  Would this still preserve
integrity?  What if there's a SHR ENQ outstanding from another job?

z/OS NFS server apparently does EXCL SPFEDIT ENQ on write; no ENQ
that I can detect on read.  Is this better?

Could it be made better for PDSE members, since they have a sort of
LUW encapsulation?

And, truly annoying:

/bin/cp /what/ever "//'SYS2.MVSMODS.CNTL(ISTINCLM)'"

requests EXCL SYSDSN ENQ.  I think this misspecification is
inherent in the C RTL.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP Get Blocked by ISPF EDIT

[Binyamin Dissen]

On Thu, 20 May 2010 09:44:07 -0700 Edward Jaffe 
wrote:

:>Did you know that z/OS ftp GET is blocked by ISPF EDIT?  =-O

:>This is a little scary since we use ftp all over the place in our 
:>automated processes!

:>ftp> cd 'sys2.mvsmods.cntl'
:>250 The working directory "SYS2.MVSMODS.CNTL" is a partitioned data set
:>ftp> get istinclm istinclm.jcltxt
:>200 Port request OK.
:>125-FTP Server unable to obtain SHARED use of 
:>SYS2.MVSMODS.CNTL(ISTINCLM) which
:>is held by: 008F EDJXADM  EXCL on SPFEDIT
:>125 Data set SYS2.MVSMODS.CNTL(ISTINCLM) is not available
:>550 SYS2.MVSMODS.CNTL(ISTINCLM) used exclusively by someone else.
:>ftp> bye
:>221 Quit command received. Goodbye.

Wouldn't the DDNAME approach work?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Of interest to the Independent Contractors on the list

[McKown, John]

> 
> All prime examples of media know-nothings trying to be "know 
> it alls". 
> Has anyone yet developed a vaccine for "stupid" ??  :-)
> 
> Rick

Yes - it induces the only cure - death.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Getting "BIND/LINK" date out of load module members

[Rick Fochtman]

---


This is very nice.
I find it perplexing, though, that there is apparently no field in a load 
module PDS that indicates when a member was created and/or last updated.  Why 
is it there for non-load module PDSs but not for load module PDSs?
 


-
The presence or absence of a creation date is dependant on the processor 
that creates the member. For 'source' members, it's usually ISPF that 
places the CRDATE in the directory entry. For load modules, the actual 
creation date is present in the IDR data within the member. I can't tell 
you anything about program objects, since I haven't worked with them.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Of interest to the Independent Contractors on the list

[Rick Fochtman]

--


Countless other professionals did corresponding good work and as a
direct consequence "Y2K" was not a disaster at all. One suspects that
sections of the media were hoping it was going to be very bad (planes
falling from the sky, toasters electrocuting their owners, elevators
plummeting and countless other pieces of mundane equipment going
Disney-dancing cranky.



At the time I was working for an ISV, and beginning 12/31/1999 all 
technical employees were "on call", and three at a time had to man the 
help line until 1/3. We got a few calls, but mostly minor stuff. 
However, at the same time the Fairfax County, Virginia government 
wasn't doing so well - they sent notice of a fine to the parents of 
someone for failing to register their four-year old for kindergarten; 
unfortunately for them the press had a field day because the four-year 
old was really a 104 year-old man.


--
Leave us not forget the one poor guy in Europe (I think it was somewhere 
in Italy) who got his 30-day jail sentence extended to 100 years + 30 days.


Or the panic about all the computers in our cars suddenly failing. 
(IIRC, there were 27 separate "computers" in a new Cadillac at the time.)


All prime examples of media know-nothings trying to be "know it alls". 
Has anyone yet developed a vaccine for "stupid" ??  :-)


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP Get Blocked by ISPF EDIT

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe
> Sent: Thursday, May 20, 2010 11:44 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: FTP Get Blocked by ISPF EDIT
> 
> Did you know that z/OS ftp GET is blocked by ISPF EDIT?  =-O
> 
> This is a little scary since we use ftp all over the place in our 
> automated processes!
> 
> ftp> cd 'sys2.mvsmods.cntl'
> 250 The working directory "SYS2.MVSMODS.CNTL" is a 
> partitioned data set
> ftp> get istinclm istinclm.jcltxt
> 200 Port request OK.
> 125-FTP Server unable to obtain SHARED use of 
> SYS2.MVSMODS.CNTL(ISTINCLM) which
> is held by: 008F EDJXADM  EXCL on SPFEDIT
> 125 Data set SYS2.MVSMODS.CNTL(ISTINCLM) is not available
> 550 SYS2.MVSMODS.CNTL(ISTINCLM) used exclusively by someone else.
> ftp> bye
> 221 Quit command received. Goodbye.
> 
> -- 
> Edward E Jaffe

Yeap, I've run into that a number of time. Editting a JCL member, do a SAVE, 
then want to ftp it to my desktop. the ftp fails.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

FTP Get Blocked by ISPF EDIT

[Edward Jaffe]

Did you know that z/OS ftp GET is blocked by ISPF EDIT?  =-O

This is a little scary since we use ftp all over the place in our 
automated processes!


ftp> cd 'sys2.mvsmods.cntl'
250 The working directory "SYS2.MVSMODS.CNTL" is a partitioned data set
ftp> get istinclm istinclm.jcltxt
200 Port request OK.
125-FTP Server unable to obtain SHARED use of 
SYS2.MVSMODS.CNTL(ISTINCLM) which

is held by: 008F EDJXADM  EXCL on SPFEDIT
125 Data set SYS2.MVSMODS.CNTL(ISTINCLM) is not available
550 SYS2.MVSMODS.CNTL(ISTINCLM) used exclusively by someone else.
ftp> bye
221 Quit command received. Goodbye.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Of interest to the Independent Contractors on the list

[Paul Gilmartin]

On Thu, 20 May 2010 09:48:07 -0500, Greg Shirey wrote:

>>From: IBM Mainframe Discussion List On Behalf Of Gerhard Postpischil
>>Sent: Thursday, May 20, 2010 2:40 AM
>
>>At the time I was working for an ISV, and beginning 12/31/1999
>>all technical employees were "on call", and three at a time had
>>to man the help line until 1/3. We got a few calls, but mostly
>>minor stuff. However, at the same time the Fairfax County,
>>Virginia government wasn't doing so well - they sent notice of a
>>fine to the parents of someone for failing to register their
>>four-year old for kindergarten; unfortunately for them the press
>>had a field day because the four-year old was really a 104
>>year-old man.
>
>That's an interesting anecdote, and one not reported in Wikipedia's
>"Documented errors" section of their Year 2000 Problem page:
>http://en.wikipedia.org/wiki/Year_2000_problem#Documented_errors
>
But that would have been a Year 1900 problem, not a Year 2000
problem, wouldn't it?  ISTR hearing the story well before 2000,
perhaps in the development ramp-up.  It likely got retold in
the press field day circa Y2K.  Summer Shark Story?  Urban
Legend?  No way to tell.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Configuring HOSTNAME for OMVS segment

[Patrick Lyon]

On Thu, 20 May 2010 15:24:34 +0100, Chokalingam Thangavelu 
 wrote:

>Hi,
>
>Please let me know 1. From where 'hostname' command in OMVS picks the
>hostname information
>   2. Do we need to change anything in OMVS side as part
>of this IP address changed activity
>

Chokalingam, see if there is a /etc/resolver.conf file.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Of interest to the Independent Contractors on the list

[Howard Brazee]

On 20 May 2010 07:49:37 -0700, wgshi...@benekeith.com (Greg Shirey)
wrote:

>>At the time I was working for an ISV, and beginning 12/31/1999 
>>all technical employees were "on call", and three at a time had 
>>to man the help line until 1/3. We got a few calls, but mostly 
>>minor stuff. However, at the same time the Fairfax County, 
>>Virginia government wasn't doing so well - they sent notice of a 
>>fine to the parents of someone for failing to register their 
>>four-year old for kindergarten; unfortunately for them the press 
>>had a field day because the four-year old was really a 104 
>>year-old man.
>
>That's an interesting anecdote, and one not reported in Wikipedia's 
>"Documented errors" section of their Year 2000 Problem page:
>http://en.wikipedia.org/wiki/Year_2000_problem#Documented_errors

This type of error has been reported various times over the years - it
was around before the term Y2K was invented.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10

[Edward Jaffe]

Nick Jones wrote:

Mark,
Sorry to pick up on this old post but we have just upgraded from z/OS 1.9 to 
z/OS 1.11 and, like you, take advantage of screen sizes in excess of 62x160.


We have the same problem with ISPF 6.1 as you had with ISPF 6.0. i.e.
TSO obeys the terminal setting of 86x190, as does SELCOPY/i when run 
directly from TSO, but ISPF switches to MOD 2.


Did you manage to get a solution (or an explination) from IBM ?
  


Every 3270 display has two sizes: the default (or primary) size and the 
alternate size. I'm running with 90x80 default size and 90x142 alternate 
size without issues.


ISPF's behaviors are driven by the "Terminal Characteristics" on the 
"ISPF Settings" panel. You get to that panel by issuing the SETTINGS 
command. It contains:


|Terminal Characteristics
|  Screen format   3  1. Data2. Std 3. Max 4. Part

If you are unable to set a usable default screen size, i.e., one 
considerably bigger than 24x80 preferably with the same number of rows 
as your alternate size, then I recommend Choosing "3. Max" as 
illustrated above.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10

[zMan]

My bad -- I meant that the entire environment is pretty stable and not
updated; it seems that it's the ISPF layer that is having trouble here, not
TSO itself. I realize they're different, but they're *almost* synonymous. My
point remains: where's the win for IBM?

On Thu, May 20, 2010 at 9:59 AM, Thompson, Steve <
steve_thomp...@stercomm.com> wrote:

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of zMan
> Sent: Thursday, May 20, 2010 8:36 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10
>
> On Thu, May 20, 2010 at 4:48 AM, Nick Jones 
> wrote:
>
> > Mark,
> > Sorry to pick up on this old post but we have just upgraded from z/OS
> 1.9
> > to
> > z/OS 1.11 and, like you, take advantage of screen sizes in excess of
> > 62x160.
> >
> > We have the same problem with ISPF 6.1 as you had with ISPF 6.0. i.e.
> > TSO obeys the terminal setting of 86x190, as does SELCOPY/i when run
> > directly from TSO, but ISPF switches to MOD 2.
> >
> > Did you manage to get a solution (or an explination) from IBM ?
> >
>
> What's to explain? TSO is old and grotty, and supporting random screen
> sizes
> in fullscreen apps is a pain. By no means impossible, of course, but a
> lot
> of work. Will making that investment sell more TSO or keep sites from
> migrating off? Unlikely... so why would they do it?
>
> Unpleasant reality, but reality nonetheless.
> 
>
> Let me see if I have this right. TSO supports the huge screen size. So
> it is old and grotty.
>
> ISPF has a problem with it and forces MOD2. But it is OK since it
> supports the workstation model with GUI.
>
> The problem with ISPF, according to one of the guys here who does more
> stuff with ISPF than I do, is that ISPF supports a smaller size --
> because for whatever reason, they [ISPF] changed things to use a smaller
> workspace/buffer/screen size/addressing (it was one of those or some
> combination). IIRC, an earlier release of ISPF *WAS* supporting the
> larger sizes (was that z/OS 1.6?).
>
> But, TSO supports the humungous screen sizes -- so it is old grotty and
> well, dead.
>
> Reality, not perception.
>
> Regards,
> Steve Thompson
>
> -- Satire by this poster may not reflect poster's employer's position.
> Opinions expressed by this poster may not reflect those of poster's
> employer. YMMV. Sales/use Taxes are the buyer's responsibility. --
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Of interest to the Independent Contractors on the list

[Greg Shirey]

>From: IBM Mainframe Discussion List On Behalf Of Gerhard Postpischil
>Sent: Thursday, May 20, 2010 2:40 AM

>At the time I was working for an ISV, and beginning 12/31/1999 
>all technical employees were "on call", and three at a time had 
>to man the help line until 1/3. We got a few calls, but mostly 
>minor stuff. However, at the same time the Fairfax County, 
>Virginia government wasn't doing so well - they sent notice of a 
>fine to the parents of someone for failing to register their 
>four-year old for kindergarten; unfortunately for them the press 
>had a field day because the four-year old was really a 104 
>year-old man.

That's an interesting anecdote, and one not reported in Wikipedia's 
"Documented errors" section of their Year 2000 Problem page:
http://en.wikipedia.org/wiki/Year_2000_problem#Documented_errors

I was hoping to read more about it, but even though you say the 
press had a field day with it, as I suppose they would, 
I can't find a story on it on the Internet.  Perhaps as news,
it's just too old to retain.   
  
Regards, 
Greg Shirey
Ben E. Keith Company

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Configuring HOSTNAME for OMVS segment

[Chokalingam Thangavelu]

Hi,

We have changed the IP address of our test mainframe and the DNS names
for the same. But when we check the hostname in OMVS segment still
showing old DNS name but MVS side it showing the new DNS name.

Please let me know 1. From where 'hostname' command in OMVS picks the
hostname information
   2. Do we need to change anything in OMVS side as part
of this IP address changed activity

Regards,
Chokalingam 

Wipro Limited (Company Regn No in UK FC 019088)
Address: Level 2, West wing, 3 Sheldon Square, London W2 6PS, United Kingdom. 
Tel +44 20 7432 8500 Fax: +44 20 7286 5703 

VAT Number: 563 1964 27

(Branch of Wipro Limited (Incorporated in India at Bangalore with limited 
liability vide Reg no L9KA1945PLC02800 with Registrar of Companies at 
Bangalore, India. Authorized share capital  Rs 3550 mn))

Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email. 

www.wipro.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of zMan
Sent: Thursday, May 20, 2010 8:36 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10

On Thu, May 20, 2010 at 4:48 AM, Nick Jones 
wrote:

> Mark,
> Sorry to pick up on this old post but we have just upgraded from z/OS
1.9
> to
> z/OS 1.11 and, like you, take advantage of screen sizes in excess of
> 62x160.
>
> We have the same problem with ISPF 6.1 as you had with ISPF 6.0. i.e.
> TSO obeys the terminal setting of 86x190, as does SELCOPY/i when run
> directly from TSO, but ISPF switches to MOD 2.
>
> Did you manage to get a solution (or an explination) from IBM ?
>

What's to explain? TSO is old and grotty, and supporting random screen
sizes
in fullscreen apps is a pain. By no means impossible, of course, but a
lot
of work. Will making that investment sell more TSO or keep sites from
migrating off? Unlikely... so why would they do it?

Unpleasant reality, but reality nonetheless.


Let me see if I have this right. TSO supports the huge screen size. So
it is old and grotty.

ISPF has a problem with it and forces MOD2. But it is OK since it
supports the workstation model with GUI.

The problem with ISPF, according to one of the guys here who does more
stuff with ISPF than I do, is that ISPF supports a smaller size --
because for whatever reason, they [ISPF] changed things to use a smaller
workspace/buffer/screen size/addressing (it was one of those or some
combination). IIRC, an earlier release of ISPF *WAS* supporting the
larger sizes (was that z/OS 1.6?).

But, TSO supports the humungous screen sizes -- so it is old grotty and
well, dead.

Reality, not perception.

Regards,
Steve Thompson

-- Satire by this poster may not reflect poster's employer's position.
Opinions expressed by this poster may not reflect those of poster's
employer. YMMV. Sales/use Taxes are the buyer's responsibility. --

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Getting "BIND/LINK" date out of load module members

[Chris Nelson]

Be careful relying on recent BIND/LINK date for an audit, someone could have 
copied in a load module that was linked 20 years ago without relinking the 
program.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10

[zMan]

On Thu, May 20, 2010 at 4:48 AM, Nick Jones  wrote:

> Mark,
> Sorry to pick up on this old post but we have just upgraded from z/OS 1.9
> to
> z/OS 1.11 and, like you, take advantage of screen sizes in excess of
> 62x160.
>
> We have the same problem with ISPF 6.1 as you had with ISPF 6.0. i.e.
> TSO obeys the terminal setting of 86x190, as does SELCOPY/i when run
> directly from TSO, but ISPF switches to MOD 2.
>
> Did you manage to get a solution (or an explination) from IBM ?
>

What's to explain? TSO is old and grotty, and supporting random screen sizes
in fullscreen apps is a pain. By no means impossible, of course, but a lot
of work. Will making that investment sell more TSO or keep sites from
migrating off? Unlikely... so why would they do it?

Unpleasant reality, but reality nonetheless.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Getting "BIND/LINK" date out of load module members

[John P Kalinich]

Kriss,

Paul Strauss was on the right track with his PDS comments.  The following
IF and ATTRIB subcommands in PDS will do what you want.  Download PDS from
http://www.cbttape.org/ftp/updates/CBT182.zip.

Regards,
John K

PDS100I PDS86 -- VERSION 8.6.12  APRIL 30, 2010

>if : last(3) then(sublist)
>attrib * short

PDS232I NAME ALIASOF   CREATED  SIZE SSI  ATTRIBUTES
PDS232I AI9RECAA  10/05/18  184K 01380920 NONE
PDS232I PDS  PDS8610/05/20  319K  PAGE, TEST, RENT, REUS,
REFR
PDS232I PDSE PDS8610/05/20  319K  PAGE, TEST, RENT, REUS,
REFR
PDS232I PDS86 10/05/20  319K  PAGE, TEST, RENT, REUS,
REFR
PDS118I 2 MEMBERS RMODE24; SIZE IS 502K


   
  From:   "Davis, Kriss" 
   

   
  To: IBM-MAIN@bama.ua.edu  
   

   
  Date:   05/19/2010 02:46 PM   
   

   
  Subject:Getting "BIND/LINK" date out of load module members   
   

   





I am working on process to monitor/audit load libraries for new/replaced
members during a date range.  I have a working version that uses AMBLIST
with a SYSIN of LISTIDR.  I run the REPORT OUTPUT created by this to a
disk dataset for a given load library.

Then in the next step, I parse the REPORT output looking for the member
name and BIND date.  If the BIND date is less than 3 days old, I output
the member name on the report.

The AMBLIST step (unloading all the member data to the report) takes
quite awhile for some of our larger LOAD libraries.  And of course,
outputs a lot more info than I need.  I just need the member name and
the BIND date.

Is there another IBM utility (or a different parameter for AMBLIST) that
would unload a LOAD library of its members and dates more efficiently?

I only run this once a day, so it is not a big deal that it runs quite a
while, but it would help testing new features if I could get the
"AMBLIST" part to run faster.

Thanks in advance!

Kriss


Kriss Davis
Manager
Illinois State University
kpda...@ilstu.edu

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ZAAPAWMT under Hiperdispatch

[Staller, Allan]

See OA31072..


In our development environment, we have dozens of Websphere App servers
running, and we only have one zAAP (on a z10-704).

The aggravation is that we have significant overflow of zAAP eligible
workload to GP engines, despite the zAAP being nowhere near 100% busy
(whereas all the GPs are 100% busy, pretty much 24x7! with a slight
respite
at weekends.).


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ZAAPAWMT under Hiperdispatch

[John Eells]

Graham Harris wrote:

In our development environment, we have dozens of Websphere App servers
running, and we only have one zAAP (on a z10-704).

The aggravation is that we have significant overflow of zAAP eligible
workload to GP engines, despite the zAAP being nowhere near 100% busy
(whereas all the GPs are 100% busy, pretty much 24x7! with a slight respite
at weekends.).




Do you have Honor Priority turned on (IFAHONORPRIORITY=YES) in IEAOPTxx, 
or off (IFAHONORPRIORITY=NO)?


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Getting "BIND/LINK" date out of load module members

[Ted MacNEIL]

>Non-load module PDS do not have dates. ISPF places a date when it creates a 
>member.

And, an update date.

But, using LM services, you can also manipulate all the fields managed by ISPF.


-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Large 3270 screen size and TSO/ISPF 6.0 on z/OS v1.10

[Nick Jones]

Mark,
Sorry to pick up on this old post but we have just upgraded from z/OS 1.9 to 
z/OS 1.11 and, like you, take advantage of screen sizes in excess of 62x160.

We have the same problem with ISPF 6.1 as you had with ISPF 6.0. i.e.
TSO obeys the terminal setting of 86x190, as does SELCOPY/i when run 
directly from TSO, but ISPF switches to MOD 2.

Did you manage to get a solution (or an explination) from IBM ?  
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Getting "BIND/LINK" date out of load module members

[Binyamin Dissen]

On Thu, 20 May 2010 02:14:33 -0600 Frank Swarbrick
 wrote:

:>Yeah, I remembered that after I wrote the message.  But honestly, that is 
even worse.  PDS should have this information.  Every other OS I know of at 
least has last update date, if not both date/time and sometimes also creation 
date or date/time.

Submit a requirement. 

:>On 5/20/2010 at 2:06 AM, in message
:>, Binyamin Dissen
:> wrote:
:>> On Thu, 20 May 2010 01:53:45 -0600 Frank Swarbrick
:>>  wrote:
 
:>> :>This is very nice.
:>> :>I find it perplexing, though, that there is apparently no field in a load 
:>> module PDS that indicates when a member was created and/or last updated.  
Why 
:>> is it there for non-load module PDSs but not for load module PDSs?
 
:>> The only thing that is in the PDS directory is what the application creating
:>> the member places there.
 
:>> Non-load module PDS do not have dates. ISPF places a date when it creates a
:>> member. A JCL created member does not have a date.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Getting "BIND/LINK" date out of load module members

[Frank Swarbrick]

Yeah, I remembered that after I wrote the message.  But honestly, that is even 
worse.  PDS should have this information.  Every other OS I know of at least 
has last update date, if not both date/time and sometimes also creation date or 
date/time.
-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403


On 5/20/2010 at 2:06 AM, in message
, Binyamin Dissen
 wrote:
> On Thu, 20 May 2010 01:53:45 -0600 Frank Swarbrick
>  wrote:
> 
> :>This is very nice.
> :>I find it perplexing, though, that there is apparently no field in a load 
> module PDS that indicates when a member was created and/or last updated.  Why 
> is it there for non-load module PDSs but not for load module PDSs?
> 
> The only thing that is in the PDS directory is what the application creating
> the member places there.
> 
> Non-load module PDS do not have dates. ISPF places a date when it creates a
> member. A JCL created member does not have a date.
> 
> --
> Binyamin Dissen 
> http://www.dissensoftware.com 
> 
> Director, Dissen Software, Bar & Grill - Israel
> 
> 
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
> 
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

>>> 

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Getting "BIND/LINK" date out of load module members

[Binyamin Dissen]

On Thu, 20 May 2010 01:53:45 -0600 Frank Swarbrick
 wrote:

:>This is very nice.
:>I find it perplexing, though, that there is apparently no field in a load 
module PDS that indicates when a member was created and/or last updated.  Why 
is it there for non-load module PDSs but not for load module PDSs?

The only thing that is in the PDS directory is what the application creating
the member places there.

Non-load module PDS do not have dates. ISPF places a date when it creates a
member. A JCL created member does not have a date.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Getting "BIND/LINK" date out of load module members

[Frank Swarbrick]

This is very nice.
I find it perplexing, though, that there is apparently no field in a load 
module PDS that indicates when a member was created and/or last updated.  Why 
is it there for non-load module PDSs but not for load module PDSs?
-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403


On 5/19/2010 at 5:50 PM, in message
, Paul
Strauss  wrote:
> Hi Kriss,
> 
> Another person replied and suggested using the free PDS tool from the
> CBTTAPE web site. That should do what you want. I made a copy of
> SYS1.CMDLIB and ran PDS85 (the name on my system) in batch to get the
> following report:
> 
> NAMEALIASOF CREATED  SIZE SSI  ATTRIBUTES
> AKJLKL0110/02/08 17832 01119368 RENT, REUS, REFR
> ARCBDEL   10/02/08 34016 01118183 RENT, REUS
> ARCRMDS   10/04/12  176K 0158 RENT, REUS
> CBRUTIL   10/04/12 12112 01110829 RANY, A31, RENT,
> REUS, REFR
> HBACK   ARCRMDS 10/04/12  176K 0158 RENT, REUS
> HBACKDS ARCRMDS 10/04/12  176K 0158 RENT, REUS
> HBDEL   ARCBDEL 10/02/08 34016 01118183 RENT, REUS
> HBDELETEARCBDEL 10/02/08 34016 01118183 RENT, REUS
> HDELARCRMDS 10/04/12  176K 0158 RENT, REUS
> HDELETE ARCRMDS 10/04/12  176K 0158 RENT, REUS
> HMIGARCRMDS 10/04/12  176K 0158 RENT, REUS
> HMIGRATEARCRMDS 10/04/12  176K 0158 RENT, REUS
> HRECA   ARCRMDS 10/04/12  176K 0158 RENT, REUS
> HRECALL ARCRMDS 10/04/12  176K 0158 RENT, REUS
> HRECOV  ARCRMDS 10/04/12  176K 0158 RENT, REUS
> HRECOVERARCRMDS 10/04/12  176K 0158 RENT, REUS
> IKJLKL01AKJLKL0110/02/08 17832 01119368 RENT, REUS, REFR
> OAMUTIL CBRUTIL 10/04/12 12112 01110829 RANY, A31, RENT, REUS, REFR
> 
> I created the above report using the following JCL:
> 
> //TSO  EXEC PGM=IKJEFT01
> //STEPLIB   DD DSN=SYS4.PDS.V8R5M0.LOAD,DISP=SHR
> //SYSPRINT DD SYSOUT=*
> //SYSTSPRT DD SYSOUT=*
> //SYSTSIN  DD *
>  PDS85 'tsoid.SYS1.CMDLIB'
>  IF : LAST(120)
>  END
> //
> 
> For the test above I made a copy of SYS1.CMDLIB in tsoid.SYS1.CMDLIB. This
> load library had 295 members.
> 
> The IF : LAST(120) above is telling PDS85 to list out the members (the :
> says all members in the dataset are included) that were linked over the
> last 120 days before today (or what ever day it was run). You wanted to run
> the type of report above going back three days but tsoid.SYS1.CMDLIB  did
> not have any load modules linked over the last 3 days which resulted in the
> job getting putting out this message 'NO MATCHING ATTRIBUTES WERE FOUND '.
> That's why I ran it with LAST(120). You should be able to get the product
> above from web site www.cbttape.org if you don't have it.
> 
> There are many other keywords for PDS. You could use CHANGED
> (1/1/10:3/15/10) instead of LAST if you need a range.   (Untested)
> 
> Good Luck.
> 
> Thank You,
> 
> Paul Strauss
> 
> Integrated Technology Delivery, Global Services, IBM
> L0DB z/OS MVS/Program Products/Security
> 150 Kettletown Rd.
> Southbury, CT 06488
> (203) 272-2758
> strau...@us.ibm.com 
> 
> 
>  
>  
>   From:   "Davis, Kriss"   
>  
>
>  
>  
>   To: IBM-MAIN@bama.ua.edu
> 
>  
>  
>   Date:   05/19/2010 06:15 PM
>  
>  
>  
>   Subject:Getting "BIND/LINK" date out of load module members
>  
>  
>  
>   Sent by:IBM Mainframe Discussion List 
>   
>   
>  
>  
> 
> 
> 
> 
> 
> I am working on process to monitor/audit load libraries for new/replaced
> members during a date range.  I have a working version that uses AMBLIST
> with a SYSIN of LISTIDR.  I run the REPORT OUTPUT created by this to a
> disk dataset for a given load library.
> 
> Then in the next step, I par

Re: Of interest to the Independent Contractors on the list

[Gerhard Postpischil]

On 5/19/2010 7:13 AM, Graeme Gibson wrote:

Countless other professionals did corresponding good work and as a
direct consequence "Y2K" was not a disaster at all. One suspects that
sections of the media were hoping it was going to be very bad (planes
falling from the sky, toasters electrocuting their owners, elevators
plummeting and countless other pieces of mundane equipment going
Disney-dancing cranky.


At the time I was working for an ISV, and beginning 12/31/1999 
all technical employees were "on call", and three at a time had 
to man the help line until 1/3. We got a few calls, but mostly 
minor stuff. However, at the same time the Fairfax County, 
Virginia government wasn't doing so well - they sent notice of a 
fine to the parents of someone for failing to register their 
four-year old for kindergarten; unfortunately for them the press 
had a field day because the four-year old was really a 104 
year-old man.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: partially initialized structures in C (3)

[Bernd Oppolzer]

Hello Dave,

thank you for your answers.

Yes, the reason for "my" confusion was twofold:

first, the documentation of IBM, which states that the remaining components
of partially initialized automatic structures are not initialized, which 
is not

conforming to the ANSI standard and is not what the compilers do

and second, the fact, that the MVI, which sets the first byte of the 
remainder

of the structure to zero and the MVC, which does the rest, are separated by
some 40 instructions from each other, so I didn't see the MVC at first look
(the function prologue is located between these instructions)

But, thanks to the mailing list, I had some closer looks and found the MVCs
in the end, which ended my confusion and the whole mess.

And: thank you for your advertisement. I like your compiler, but I will not
be able to convince my customer to try it - they are very IBM bound, in
my opinion.

Kind regards

Bernd



Thomas David Rivers schrieb:

I'm pretty confident the IBM compiler follows the ANSI C standard
and that some other reason is the cause of the confusion.

If you discover it doesn't, and it's a problem; might I humbly
offer our alternative (which can operate in your LE environment.)
We definately would initialize that structure to all zeros.

And, if you're recompiling anyway... might as well give
our compiler a try...

Just a (partially shameless) plug.

- Dave Rivers -




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html