No need to have empty members -- an empty PDS does about as well.
There are things that an empty member would not catch. Suppose the program
COPYed functional statements into the middle of some executable section. The
code might well compile cleanly without them. Not typical, but possible.
In a
On Fri, 22 Mar 2013 12:07:50 -0500, Ron Thomas wrote:
>Hello. Could some one let us know how to create a process which extracts all
>copybooks from a program and looks in to the copybook library and check if it
>exists , if exists reads the copybook variables in the copybook and search
>in t
On Fri, 22 Mar 2013 18:26:38 -0500, Walt Farrell wrote:
>On Fri, 22 Mar 2013 15:18:48 -0400, Tony Harminc wrote:
>
>>In the long term, of course, RACF will surely change to allow phrases
>>to be as short as anyone likes, subject only to installation control,
>>and passwords to be optional, and the
Excellent advice.
> The compiler has done 99.9% of the hard work at this point.
And done it exactly the way the compiler does it -- in other words, this
moots my last point about the syntactically questionable program.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mail
On 22 March 2013 14:50, EXT-Schwarz, Barry wrote:
> My mistake about after. How about during? On the TSO logon panel, if you
> enter the correct passphrase, do you also
> need to enter the current password when you enter a new password? I would
> test it but we don't have phrases active.
No
On Fri, 22 Mar 2013 15:18:48 -0400, Tony Harminc wrote:
>In the long term, of course, RACF will surely change to allow phrases
>to be as short as anyone likes, subject only to installation control,
>and passwords to be optional, and then we'll have by a very long and
>roundabout route what everyo
I am out of the office until 03/27/2013.
Passover prep and first day of Passover. IF an emergency, call
845-901-2328.
Note: This is an automated response to your message "Re: PDS Compress"
sent on 03/22/2013 16:37:46.
This is the only notification you will receive while this person is away.
-
Tony,
A LONG time ago and far far away we leaned a couple of lessons about
IEBCOPY.
Its a great utility and it must be used with care.
SMPE was a user of IEBCOPY and we greatly speeded it up by passing
the parm SIZE=MAX and along with specifying a large size=(8192K,99K)
on the linkage edi
I graduated from University of Florida (UFL) and am currently
running a computer firm in Florida. I have attended WORLDCOMP
conference (see http://sites.google.com/site/worlddump1 for
details) in 2010. Except for few keynote speeches and
presentations, the conference was very disappointing due
On 22 March 2013 09:43, Steve Thompson wrote:
> I'm going to ask a dumb question. I do not expect an answer.
>
> Did you have the SYSUT3 and SYSUT4 DDs specified? If so, were they
> specified in CYL not TRK, and with NO secondary, and CONTIG?
I'm not sure whether you're asking your "dumb questi
On 22 March 2013 14:50, EXT-Schwarz, Barry wrote:
> My mistake about after. How about during? On the TSO logon panel, if you
> enter the correct passphrase, do you also need to enter the current password
> when you enter a new password? I would test it but we don't have phrases
> active.
He
> Unfortunately GTF terminates itself with a dump of title DUMP OF GTF
> MODULE AHLTUSR. Again unfortunately, that dump does not contain any
> system trace table. All I have for debugging is the (2) logrec
> entries for this:
>
> PSW: 04041001 8000 05D02EB8
>INSTRUCTION LENGTH:
My mistake about after. How about during? On the TSO logon panel, if you
enter the correct passphrase, do you also need to enter the current password
when you enter a new password? I would test it but we don't have phrases
active.
> -Original Message-
> From: IBM Mainframe Discussion
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Joel C. Ewing
> Sent: Friday, March 22, 2013 9:08 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
>
> Noticing that this thread
Personally, I'd really prefer to have someone do a compile of the source,
using the ADATA compile parameter. Output the ADATA to a sequential data
set (or member of a PDS), then read that. The compiler has done 99.9% of
the hard work at this point.
ADATA reference:
http://publibz.boulder.ibm.com/c
FIXPDS does a good job of recovering 'old' copies of members. Have used it
many times for broken and not backed up datasets. Some groups are worse
than others about compressing w/o looking at condition codes!
In a message dated 3/22/2013 4:47:06 A.M. Central Daylight Time,
bernd.oppol...
As one who has done it as part of a larger product, it is a bear.
If you don't mind a few false positives, then just parsing for the word COPY
and picking off the next token (as someone else wrote), and optionally OF
ddname, will get you there.
COBOL syntax is downright ugly, and doing it righ
Do you have a change control product (chgman, endevor erc)?
They have this usually as part of the product
Do you use sclm?
Otherwise, you will be building this process. Check the cbttape.org and see if
there is something there.
Lizette
-Original Message-
>From: Ron Thomas
>Sent: Ma
http://www.mackinney.com/products/program-development/cobol-glossary.html
Search for 'cobol cross reference'
On Fri, Mar 22, 2013 at 12:07 PM, Ron Thomas wrote:
> Hello. Could some one let us know how to create a process which extracts all
> copybooks from a program and looks in to the copybook
This is easy by Rexx.
Phase 1"Do an EXECIO to read the source into a stem. The parse for the word
copy and lines that are not marked with an asterisk at column 7. For each
copy member name, create an entry the copies stem. You can make the rest of
phases easier if you remove all Cobol reserved word
Hello. Could some one let us know how to create a process which extracts all
copybooks from a program and looks in to the copybook library and check if it
exists , if exists reads the copybook variables in the copybook and search in
the program and writes the lines which uses the variable to
I seem to recall that a utility which may still be around called 'Ditto' could
perform this kind of recovery/magic.
Perhaps someone with a better memory could confirm or deny.
Mike Duffy
--
For IBM-MAIN subscribe / signoff / ar
Noticing that this thread continues to focus on how to make a recall of
the PROCLIB dataset work, I think it should be re-emphasized that any
managed data set that is essential to the proper functioning of JES2, or
any other critical started task at your site, should really be assigned
a Manage
Hello,
with regard to the undocumented use of the "optimize" parameter on dfdss copy,
those nice people at Ibm in Dfdss R&D have opened a marketing req to get it
fully supported and also an apar which will ignore it if coded with copy.
"We have the following Marketing Requirement opened:
User
Hervey,
Thanks. I tried the FORENONSMS because it was suggested.
From: Hervey Martinez
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, March 22, 2013 10:47:24 AM
Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
From the message, it appears tha
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL
-Original Message-
From: "Don Williams"
Date: Thu, 21 Mar 2013 00:18:10
To:
Reply-To:
Subject: RE: Query for Destination z article -- mainframes back to the future
Great point.
> -Original Message-
> From: eamacn...@yahoo
>From the message, it appears that the volume SMTP17 is an SMS volume but the
>command has FORCENONSMS. A file can be recalled to a non-sms volume..have done
>it several times.
Regards,
Hervey
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On B
Charles Mills wrote:
>Good question. The big problem is at one customer.
Thanks. That could helps you to narrow your search to a solution.
>So the answer to your question is a little unclear. 1 or 2 customers out of 3.
Ok. Then I'm out of ideas and any possible contributions to your problem
s
On 03/22/2013 04:31 AM, Ravi Gaur wrote:
We had a very weird situation where one of the TSO user compressed the PDS
dataset which had 6000+ members however eventually the JCL in all of these
members got similar atmost ..so look like during stow somehow same memory
overlaid or Directory TTR got
Good question. The big problem is at one customer. We have another customer --
z/OS release number question still pending -- that is running the possibly
problematic code with no issue.
There was one POC where the prospect installed the product, which supports the
use of TCP or UDP. The prospec
Wilie,
You are correct.
Since the problem is with a PROCLIB, restoring it to the same Volume is not
as relevant as restoring to the same TTRs. If it gets restored to the same
volume, but not the same TTRs, then you will still need to open/close
proclibs in-order to get JES2 to refresh its inform
On Fri, 2013-03-22 at 09:43 -0400, Steve Thompson wrote:
> Requirement: SYSUT4 must be in a single contiguous extent
> -- z/OS DFSMSdfp Utilities SC26-7414-03
I was surprised to read this, after 40 years of coding IEBCOPY jobs.
Thanks for digging this up, Steve.
I also found in
Steve Thompson wrote:
>I'm going to ask a dumb question. I do not expect an answer.
It is not a dumb question. The OP said 'one of the TSO user compressed the PDS
dataset ...'. But it is somewhat ambiguous. It is not really clear how the
compression was done: in batch or TSO?
TSO is supposed t
Am I safe to assume that what I am trying to do cannot be done?
From: Mike Schwab
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, March 22, 2013 9:32:59 AM
Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
If it is SMS managed, then the volume does
From: Ravi Gaur
Date: 03/22/2013 05:31 AM
We had a very weird situation where one of the TSO user compressed the PDS
dataset which had 6000+ members however eventually the JCL in all of these
members got similar atmost ..so look like during stow somehow same memory
overlaid or Directory
The OS does not guarantee space, the phrase indicates that the user will
guarantee there is space. That is, the normal operation for SMS is to locate
space on an appropriate volume; "guaranteed space" subverts this normal process
and uses the VOLSER value the user has coded.
Greg Shirey
Ben E
If it is SMS managed, then the volume doesn't matter.
You specified a specific volume, so I assumed a non-sms volume.
On Fri, Mar 22, 2013 at 8:28 AM, willie bunter wrote:
> Elardus,
>
> I tried your suggestion :
>
> HSEND RECALL 'HESPDE02..ABACKUP.IMS1.HLIST' DFDSSOPTION(VOLCOUNT(ANY)) -
> FO
Elardus,
I tried your suggestion :
HSEND RECALL 'HESPDE02..ABACKUP.IMS1.HLIST' DFDSSOPTION(VOLCOUNT(ANY)) -
FORCENONSMS VOLUME(SMTP17) UNIT(3390)
/*
However it didn't work. According to the error message ADR472E 72 :
D
willie bunter wrote:
HSEND RECALL 'HESPDE02.ABACKUP.IMS1.HLIST' DFDSSOPTION(VOLCOUNT(ANY)) -
FORCENONSMS VOLUME(SMTP17) -
BYPASSACS(**) -
NULLSTORCLAS
Where is your UNIT() keyword? As documented, you MUST specify UNIT when
specify VOLUME. (and vice versa too).
I'm not sure about inlusion o
On Fri, 22 Mar 2013 07:13:49 +0100, nitz-...@gmx.net wrote:
>
>> Check: GRS_CONVERT_RESERVES
>> Comment: Still haven't used the GRS ENQ/DEQ/RESERVE Monitor to check
>> what reserves our systems are using. I was wondering has anyone tried
>> to convert all RESERVEs to ENQs? Were any applications p
John,
According to Lizette's post it won't make a difference. Lizette please correct
me if I misspoke:
"JES2 requires that the data map to the same TTR. So the proclib could be
moved, but the tracks not over written. So the TTRs would still be valid for
that proc. The minute the space
Mike,
I tried out your suggestions but I was unable to get it running. The dsn is in
ML1 status. According to the error messages a BYPASSACS is required.
However I tried that and did not work. I tried NULLSTORCLAS as well but I
receive the error :
ARC1001I RECALL 'HESPDE02.ABACKUP.IMS1.HLI
Walter,
I was able to recall other ML2 dsns to the original volumes by putting all the
volumes (for that specific SG) in DISNEW status and only enabling the volume
where the dsn is to be recalled. It is not a very scientific approach however
it did the job eventhough it is quick and dirty.
G'day,
In further to Willie's post, what if the dsn was recalled to the proper or
original volume, must the JES2 proc need to be refreshed because the dsn may
not have been placed on the same track or cylinder?
From: Walter Marguccio
To: IBM-MAIN@LISTSERV.UA.
Hello,
for those of you with DS8x00 series disk systems you've probably already seen
the latest alerts, but if not:-
http://www-947.ibm.com/support/entry/portal/Planning/Hardware/System_Storage/Disk_systems/Enterprise_Storage_Servers/DS8300/
leads to
http://www-01.ibm.com/support/docview.wss?
Hi,
As of z/OS 1.10, The XCF_SIG_STR_SIZE check supports a parameter that
lets you indicate whether you want to check the size of the structure based
on the number of systems actually in the sysplex OR the maximum number of
possible systems in the sysplex per the sysplex couple data set. T
I don't think that I will find it, because the episode was some 15 years
ago,
but I'll try ... I'll send you an answer later today.
Am 22.03.2013 10:56, schrieb Ravi Gaur:
Do you have the code of assemble to read the directory sequentially and create
members...
--
Thankyou yes I looked at the PDSGAS and it's a good utility for recovering the
deleted members until pds is not compresses or space is not reclaimed..However
in current situation it just show me similar JCL..We going back to 2011
backup...It doesn't have HSM Bcds entry...Unfortunately most of u
If you can go to the CBTTAPE.ORG and find the PDS function, it has some
recovery options. PDSGAS will restore based on TTR. Not pretty but might
help. However, if you have deleted the orginal dataset, then all information
for recovery is lost. Only hope would be an HSM backup/dump or DR volu
Yesterday I needed to turn on gtf tracing to catch a problem involving about 80
address spaces. I am tracing user records issued at a really rapid rate by
those 80 asids.
Unfortunately GTF terminates itself with a dump of title DUMP OF GTF MODULE
AHLTUSR. Again unfortunately, that dump does not
Ravi Gaur wrote:
>We had a very weird situation where one of the TSO user compressed the PDS
>dataset which had 6000+ members however eventually the JCL in all of these
>members got similar atmost ..so look like during stow somehow same memory
>overlaid or Directory TTR got wrong...
REGION siz
Do you have the code of assemble to read the directory sequentially and create
members...
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
We also once had a situation like this, where a PDS with ca. 12.000
members got
unusable during compress, the directory was overwritten and unusable.
But we managed to read the members sequentially without using the
directory,
this way moving the members to another dataset, naming them with gen
We had a very weird situation where one of the TSO user compressed the PDS
dataset which had 6000+ members however eventually the JCL in all of these
members got similar atmost ..so look like during stow somehow same memory
overlaid or Directory TTR got wrong...
We had no backup of the dataset
Charles Mills wrote:
>I have told the customer that it may be our problem
In all your posts, you're speaking of one? customer. Do this problem appears at
your other customers?
Groete / Greetings
Elardus Engelbrecht
--
For IBM
55 matches
Mail list logo
