Re: z/OS BDAM question

[Mick Graley]

Nah - it's actually how they are on the IBM manual page - weird.


On Fri, 2 Nov 2018 at 15:38, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On 2018-11-02, at 05:39:38, R.S. wrote:
> > ...
> > Content-Transfer-Encoding: 8bit
> > Content-Type: text/plain; charset="utf-8"; format=flowed
> >
> > ... 16␠777␠215 tracks ...
> >
> I had to look it up:
> The following table lists some symbols, in decreasing order by
> practical usefulness.
> Their shapes vary by font; especially the last one varies a lot.
> ␣   U+2423  OPEN BOX
> ␢   U+2422  BLANK SYMBOL
> ␠   U+2420  SYMBOL FOR SPACE
>
> Eek!  Do they always write numbers that way in Poland?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS BDAM question

[Mick Graley]

Another poster (sorry I deleted the post so can't credit him) already
stated that the addressable range depends on the method you use to access
the data set.
Yes relative track addressing is 2 bytes and limited to 64K tracks.
But relative block addressing is 3 bytes and so limited to 16M blocks.
So depending on your block size you can address more than the physical
limit of the data set.
However, as Curtis has just pointed out, Adabas itself doesn't use BDAM, it
uses EXCP/EXCPVR.
And yes Curtis you are correct - most of our Adabas data sets are DSORG=DA
but some of them are indeed DSORG=PS.
Because I inherited these systems I'm not quite sure why.
Must be something to do with the way they were first allocated and
formatted (maybe different releases of Adabas), but it doesn't make a
difference, they both work fine.
Cheers,
Mick.


On Fri, 2 Nov 2018 at 12:30, Giliad Wilf <
00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote:

> Interesting.
> I recall two statements, probably from two different sources:
>
> One states that BDAM does not support large format datasets.
>
> The other states that DA datasets accessed by relative track address are
> limited to 65536 tracks.
>
> ...so, I must assume ADABAS has a way for accessing records of a dataset
> that large...
>
> On Fri, 2 Nov 2018 11:32:23 +, Mick Graley 
> wrote:
>
> >Hi All,
> >
> >I can confirm that there is no 64K tracks limit on DSORG=DA data sets.
> >I inherited a number of Adabas databases and they use DSORG=DA.
> >One of my larger databases has a data storage component that is 240,525
> >tracks (16,035 cylinders) in 9 extents across 8 volumes.
> >
> >Organization  . . . : DA
> >Record format . . . : F
> >Record length . . . : 5064
> >Block size  . . . . : 5064
> >1st extent cylinders: 363
> >Secondary cylinders : 1668
> >Allocated cylinders : 16,035
> >Allocated extents . : 9
> >
> >The rules are documented here:
> >
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm
> >
> >Cheers,
> >
> >Mick.
> >
> >
> >On Sat, 27 Oct 2018 at 01:10, Steve Smith  wrote:
> >
> >> BDAM implies DSORG DA, but can use any RECFM.  However, DSORG DA files
> are
> >> usually physically equivalent to DSORG PS, and often are so designated.
> >> However, most DA files I've seen are indeed RECFM=F.
> >>
> >> sas
> >>
> >> On Fri, Oct 26, 2018 at 11:40 AM Tom Sims  wrote:
> >>
> >> > Datacom may use some method of "direct access," but the datasets
> >> > themselves are RECFM=F.
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS BDAM question

[Mick Graley]

Hi Radoslaw,
That's true, but I believe the OP was asking whether the entire data set
was limited to 64K tracks and I believe only PDS and PDS/E are limited to
one volume.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/d4002.htm
None of my database data sets (DB2, IMS, Adabas) are limited to one volume.
Cheers,
Mick.


On Fri, 2 Nov 2018 at 11:58, R.S.  wrote:

> Mick,
> You are still missing the point: 64k TRK limit is PER VOLUME. It regards
> PDS, (basic) PS, and DA.
> In other words, BDAM datasets are 64k TRK constrained as some other
> datasets are.
> Of course some (PDS) datasets cannot be multivolume, while DA (and PS)
> can be, but that's different story.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
>
> W dniu 2018-11-02 o 12:51, Mick Graley pisze:
> > Hi  Radoslaw,
> > If you combine all the rules for direct data sets across 2 or 3 pages of
> > the manual you get:
> > 65,535 tracks per volume, 59 volumes, 16 extents per volume, 255 extents
> > across all volumes.
> > Which suggests to me a limit of 3,866,565 tracks.
> > Cheers,
> > Mick.
> >
> >
> > On Fri, 2 Nov 2018 at 11:40, R.S. 
> wrote:
> >
> >> Documentations says the following:
> >>
> >> /Many types of data sets *are limited* to 65␠535 total tracks allocated
> >> on any one volume, and if a greater number of tracks is required, this
> >> attempt to create a data set will fail./
> >>
> >> //
> >> /Data sets that *are not limited* to 65␠535 total tracks allocated on
> >> any one volume are: /
> >>
> >>* /A large format sequential; but cannot occupy more than 16␠777␠215
> >>  tracks on a single volume. /
> >>* /Extended-format sequential/
> >>* /UNIX files/
> >>* /PDSE/
> >>* /VSAM/
> >>
> >> ...lack od BDAM files here
> >>
> >> I think, you missed very important point: 64k tracks *PER VOLUME*. The
> >> limit is not per dataset.
> >>
> >>
> >> --
> >> Radoslaw Skorupka
> >> Lodz, Poland
> >>
> >>
> >>
> >>
> >>
> >>
> >> W dniu 2018-11-02 o 12:32, Mick Graley pisze:
> >>> Hi All,
> >>>
> >>> I can confirm that there is no 64K tracks limit on DSORG=DA data sets.
> >>> I inherited a number of Adabas databases and they use DSORG=DA.
> >>> One of my larger databases has a data storage component that is 240,525
> >>> tracks (16,035 cylinders) in 9 extents across 8 volumes.
> >>>
> >>> Organization  . . . : DA
> >>> Record format . . . : F
> >>> Record length . . . : 5064
> >>> Block size  . . . . : 5064
> >>> 1st extent cylinders: 363
> >>> Secondary cylinders : 1668
> >>> Allocated cylinders : 16,035
> >>> Allocated extents . : 9
> >>>
> >>> The rules are documented here:
> >>>
> >>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm
> >>> Cheers,
> >>>
> >>> Mick.
> >>>
> >>>
> >>> On Sat, 27 Oct 2018 at 01:10, Steve Smith  wrote:
> >>>
> >>>> BDAM implies DSORG DA, but can use any RECFM.  However, DSORG DA files
> >> are
> >>>> usually physically equivalent to DSORG PS, and often are so
> designated.
> >>>> However, most DA files I've seen are indeed RECFM=F.
> >>>>
> >>>> sas
> >>>>
> >>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2018 r. wynosi 169.248.488 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this 

Re: z/OS BDAM question

[Mick Graley]

Hi  Radoslaw,
If you combine all the rules for direct data sets across 2 or 3 pages of
the manual you get:
65,535 tracks per volume, 59 volumes, 16 extents per volume, 255 extents
across all volumes.
Which suggests to me a limit of 3,866,565 tracks.
Cheers,
Mick.


On Fri, 2 Nov 2018 at 11:40, R.S.  wrote:

> Documentations says the following:
>
> /Many types of data sets *are limited* to 65␠535 total tracks allocated
> on any one volume, and if a greater number of tracks is required, this
> attempt to create a data set will fail./
>
> //
> /Data sets that *are not limited* to 65␠535 total tracks allocated on
> any one volume are: /
>
>   * /A large format sequential; but cannot occupy more than 16␠777␠215
> tracks on a single volume. /
>   * /Extended-format sequential/
>   * /UNIX files/
>   * /PDSE/
>   * /VSAM/
>
> ...lack od BDAM files here
>
> I think, you missed very important point: 64k tracks *PER VOLUME*. The
> limit is not per dataset.
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> W dniu 2018-11-02 o 12:32, Mick Graley pisze:
> > Hi All,
> >
> > I can confirm that there is no 64K tracks limit on DSORG=DA data sets.
> > I inherited a number of Adabas databases and they use DSORG=DA.
> > One of my larger databases has a data storage component that is 240,525
> > tracks (16,035 cylinders) in 9 extents across 8 volumes.
> >
> > Organization  . . . : DA
> > Record format . . . : F
> > Record length . . . : 5064
> > Block size  . . . . : 5064
> > 1st extent cylinders: 363
> > Secondary cylinders : 1668
> > Allocated cylinders : 16,035
> > Allocated extents . : 9
> >
> > The rules are documented here:
> >
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm
> >
> > Cheers,
> >
> > Mick.
> >
> >
> > On Sat, 27 Oct 2018 at 01:10, Steve Smith  wrote:
> >
> >> BDAM implies DSORG DA, but can use any RECFM.  However, DSORG DA files
> are
> >> usually physically equivalent to DSORG PS, and often are so designated.
> >> However, most DA files I've seen are indeed RECFM=F.
> >>
> >> sas
> >>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2018 r. wynosi 169.248.488 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169,248,488 as at 1 January 2018.
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS BDAM question

[Mick Graley]

Hi All,

I can confirm that there is no 64K tracks limit on DSORG=DA data sets.
I inherited a number of Adabas databases and they use DSORG=DA.
One of my larger databases has a data storage component that is 240,525
tracks (16,035 cylinders) in 9 extents across 8 volumes.

Organization  . . . : DA
Record format . . . : F
Record length . . . : 5064
Block size  . . . . : 5064
1st extent cylinders: 363
Secondary cylinders : 1668
Allocated cylinders : 16,035
Allocated extents . : 9

The rules are documented here:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm

Cheers,

Mick.


On Sat, 27 Oct 2018 at 01:10, Steve Smith  wrote:

> BDAM implies DSORG DA, but can use any RECFM.  However, DSORG DA files are
> usually physically equivalent to DSORG PS, and often are so designated.
> However, most DA files I've seen are indeed RECFM=F.
>
> sas
>
> On Fri, Oct 26, 2018 at 11:40 AM Tom Sims  wrote:
>
> > Datacom may use some method of "direct access," but the datasets
> > themselves are RECFM=F.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ISF.CONNECT.*

[Mick Graley]

I believe turning off "write to programmer" messages with TSO PROFILE
NOWTPMSG will hide the ICH408I but you might miss something else you want
to see.
Cheers,
Mick.


On 4 July 2018 at 09:47, Barbara Nitz  wrote:

> Something has changed with SDSFAUX between z/OS 2.1 and z/OS 2.3.
>
> Under z/OS 2.3, each and every user gets a RACF Message when they access
> their part of SDSF (that's the primary RACF panel). That missing right is
> for ISF.CONNECT.system, which is described as access to SDSFAUX. None of
> those users have any need to execute function provided by SDSFAUX, so I see
> no reason to give them read in that profile. This did not happen under 2.1.
> These users can work normally with SDSF after the ICH408I. The RACF error
> is mostly irritating to them and ugly.
>
> Why is the check for that right not 'silent' like all the others?
>
> Short of granting the right, is there any way to make the RACF message go
> away?
>
> Regards, Barbara
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Old School Maintenance Philosophy -- Never ACCEPT?

[Mick Graley]

I (used to) do something similar with a few added steps:

DFDSS dump the whole SMP/E environment
ACCEPT CHECK
ACCEPT
RECEIVE
APPLY CHECK (there are sometimes system holds that need addressing before
APPLY and this gets the report out as well as doing the APPLY CHECK)
APPLY

It's probably worth noting that I'm a DB2 SysProg/DBA rather than a z/OS
SysProg.
The z/OS boys do all the SMP/E work in my current shop.

Cheers,

Mick.


On 24 May 2018 at 05:11, Ed Jaffe  wrote:

> On 5/23/2018 9:30 AM, Jesse 1 Robinson wrote:
>
>> Open any IBM doc on SMP(/E) ever published and you will find the same
>> canonical procedure:
>>
>> --RECEIVE
>> --APPLY
>> --ACCEPT (maybe hold off on this a while, but resolve to do it eventually)
>>
>
> FWIW, I always do it this way:
> --ACCEPT
> --RECEIVE
> --APPLY
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/
> 
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to be
> free of any virus or other defect that might affect any computer system
> into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Mick Graley]

It's also worth noting that you can use wild cards in the HRECALL data set
name if you can be that generic, i.e. bring back ALL migrated generations
with a single HRECALL command. I use it a lot to recall all my personal
code libraries before I go on overnight call-out - I hate waiting for data
set recalls when I'm trying to fix things in the early hours of the morning!
Cheers,
Mick.


On 20 December 2016 at 21:13, George, William@FTB 
wrote:

> Thanks all.  At this point it looks like Sri's LISTCAT/SORT/RECALL or a
> REXX exec to do all the similar steps in one.
> The Extended GDG I believe would be overkill in terms of catalogued
> datasets.
>
> Bill
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of George, William@FTB
> Sent: Tuesday, December 20, 2016 11:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens
>
> Bottom Line: I am looking for a means to RECALL a block of migrated GDS
> (GDG generation datasets) from the previous month via a monthly task.
>
> BACKGROUND
> First, I'm in applications not systems.
> Second, we are changing our storage management system where we must now
> define (and redefine existing) GDG's with SCRATCH.  Most were unfortunately
> defined with NOSCRATCH so there are a boatload of uncatalogued dataset on
> the system for those that fell out of the GDG's LIMIT parm. .Plus, our
> current FDR storage management system archives all the GDS' long before
> they would even drop off the LIMIT, but that is beside the point here other
> than setting the LIMIT really didn't have much priority because of this..
> The point is our GDS are archived and are always available even GDS dropped
> off the LIMIT YEARS ago. This allowed us to go as far back a necessary to
> research issues. Now times are changing and Storage management, rightly so,
> wants to clean up all the uncatalogued datasets and fix this situation..
> With the new system coming in the automatic FDR archiving of generation
> datasets is going away and as mentioned above, GDGs are to be defined with
> SCRATCH.  Because of the SCRATCH option where GDS' are deleted when dropped
> off via the LIMIT we will need to reassess the LIMIT option on them to
> allow for proper data recovery and research considerations. We frequently
> get requests to look back at old data for various reasons.
>
> Our main concern are the GDS' allocated daily as we are required to have
> seven years of data available. We will update all pertinent daily GDGs to
> the max LIMIT of 255.  However, this only is 'about' one year's worth of
> data. We have some 500+ daily GDGs that have generations allocated. So
> backup/archiving of these is a necessity.
>
> ISSUE:
> The current plan is to run a month's end job to backup/archive all of the
> previous month's daily GDS into several ADRDSSU dump datasets with a naming
> convention that indicates what MM of data is contained within.
> However, ADRDSSU will not pick up any dataset in a MIGRAT status. So these
> must be RECALL'ed prior to the dump.
>
> QUESTION:
> Is there a means to call in, or do a HRECALL on a block of GDS? For
> example Gens -0 thru -31 without out having to code each gen separately?
> Of course gens 0 thru about -7 will probably not be migrated at this point
> but you get the idea... hopefully.
> I can certainly do this with a REXX exec doing a HRECALL on each needed
> but would like to avoid that if possible.
>
> Any insights would be appreciated.
>
> Thanks!
> Bill
>
> __
> CONFIDENTIALITY NOTICE: This email from the State of California is for the
> sole use of the intended recipient and may contain confidential and
> privileged information. Any unauthorized review or use, including
> disclosure or distribution, is prohibited. If you are not the intended
> recipient, please contact the sender and destroy all copies of this email.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A true discussion in today's world (at least here)

[Mick Graley]

I'm a DB2 SysAdm/SysProg and DB2 maint always has reams of hold data. The
longer you leave it the bigger the job to wade through it all and build the
required jobs. Multiply it by many DB2 sub-systems and the job gets bigger
and bigger. You have to have the toleration fixes on the current release of
DB2 before you can upgrade to the next release (in case of fallback to the
old release with the new release catalog/directory structure) and that can
be a big job if you are way back on maintenance.
Cheers,
Mick.


On 24 November 2016 at 05:35, Edward Gould  wrote:

> > On Nov 23, 2016, at 8:32 PM, Joel C. Ewing  wrote:
> >
> > I think the car analogy with computer systems  breaks down on a number
> > of points (at least in the case of mainframes):
> >(1) while bleeding-edge-current is certainly not essential, the
> > further you get behind on software maintenance, the more costly it gets
> > in terms of time and person-hours to get reasonably current; and without
> > being reasonably current you may not be able to utilize new hardware
> > that could be more cost effective, or needed when old hardware dies, or
> > needed to adapt to growing business requirements.  The  cost of failure
> > to do preventive maintenance on a car is bounded by the time and cost
> > for replacement transportation, no matter how much maintenance was
> skipped.
> >(2)software maintenance relating to security or data exposures may
> > need prompt attention to avoid much more expensive data loss or data
> > exposure scenarios, which may also have serious legal implications.
> > Failure to do preventive maintenance on a car doesn't generally make it
> > more susceptible to hackers or have legal implications, unless you fail
> > to repair an obvious safety hazard and that results in a personal-injury
> > accident or death..
> >(3)Unexpected failures of a lesser-maintained car more often than
> > not just causes a temporary loss of availability which with sufficient
> > funds can be easily resolved, as there are many ready substitutes for
> > the basic function of transportation.  A corporate computer system has
> > company-specific data and company-specific applications which cannot
> > just be replaced by any generic computer system, and it may be
> > impossible for the company to stay in business very long without that
> > data and those applications.  Recovery from some software failures that
> > result in data loss is only possible with adequate DR planning in place,
> > and if adequate planning was not in place, recovery may not even be
> > possible at any price.  While I believe a valid argument can be made
> > against applying maintenance just for the sake of maintenance, some of
> > the problems addressed by HIPER PTFs are so dire you really don't want
> > to wait for that failure to occur before installing the fix.
> >
> > Even with a car, while it may be cost-effective to avoid or stretch out
> > some preventive or recommended maintenance, I strongly suspect it would
> > not on balance be cheaper for you to take that to the extreme and, say,
> > never change the engine oil (unless of course your plan is to sell
> > the.car after a few years without disclosing the potential shortened
> > engine life and cheat the next owner).
> >Joel C. Ewing
> about 20 years ago I worked at such a place. They did NOT believe in
> applying maintenance.
> Along comes the Y2K problem and they were in a bind (to say the least).
> They decided to order a servpac (new at the time).
> They were a  big user of DB2 (I have no knowledge of it) but they were
> really hurting in order to get up to snuff.
> They were non going to ORDER COBOL (current as it cost $5 more than the
> old) then LE hit them in the face and they *HAD* to order that. That almost
> burst their gut.
> I am glad I got out of there.
> Ed
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A true discussion in today's world (at least here)

[Mick Graley]

I agree with Tony, the analogy doesn't fit. Not fixing a car that isn't
broken makes sense. Not applying fixes for KNOWN errors usually doesn't
make sense. We all know that PTFs can go PE and cause problems, but you
have to weigh up the likelihood of a known error causing you serious
problems. Also your car failing doesn't normally cost your business
millions of £$€.
Cheers,
Mick.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] LRECL=255 vs LRECL=259

[Mick Graley]

I think Ed might be right here on the SYSGEN option history, however TSO
EDIT doesn't seem to support it fully these days.
I have access to 5 very different systems each with different heritage.
Two of them are >30 years old and will date back to the SYSGEN days, one of
them I'm not sure of it's age, but the other two are much younger.
All of them use an FB 80 SYSPROC concatenation except for one of the older
systems which uses a VB 255 SYSPROC concatenation.
TSO EDIT creates a VB,255,3120 data set for type CLIST on all the systems
except for the older FB 80 system, which creates a corrupt FB,80,3120 data
set. I'm guessing that the original SYSGEN option of FB was copied across
for this system, but it doesn't look like TSO EDIT fully supports it as
it's obviously still using variable length edit buffers, but writing full
FB 80 byte records to the new PDS with the line numbers at the beginning of
the record rather than in columns 72-80. Here is a transcript of a TSO
session on the older FB system to demonstrate this:

 READY
listds temp.clist
 IKJ58503I DATA SET xx.TEMP.CLIST NOT IN CATALOG
 READY
e temp(hello) cl
 IKJ52320I DATA SET OR MEMBER NOT FOUND, ASSUMED TO BE NEW
 INPUT
 00010 proc 0
 00020 write hello mick
 00030 end
 00040
 E
l
 00010 PROC 0
 00020 WRITE HELLO MICK
 00030 END
 IKJ52500I END OF DATA
end save
 READY
listds temp.clist
 xx.TEMP.CLIST
 --RECFM-LRECL-BLKSIZE-DSORG
   FB803120PO
 --VOLUMES--
   vv
 READY
print inda(temp.clist(hello)) char

 RECORD SEQUENCE NUMBER - 1

 0010PROC 05...IBMOSVS2
..&&..QS
.

 RECORD SEQUENCE NUMBER - 2

 0020WRITE HELLO MICK..IBMOSVS2
..&&..QS
.

 RECORD SEQUENCE NUMBER - 3

 0030ENDTE HELLO MICK..IBMOSVS2
..&&..QS
.

 IDC0005I NUMBER OF RECORDS PROCESSED WAS 3

 READY

exec temp.clist(hello)

 0010PROC 05 -È--  IBMOSVS2ØØ -- °  - &   Ø&  -  -QS  -

 IKJ56545I THIS STATEMENT HAS AN INVALID SYMBOLIC VARIABLE

 READY



Same member shown in ISPF/PDF browse:
0010PROC 05..È. ..IBMOSVS2
...ØØ°&...Ø&..QS.
0020WRITE HELLO MICK..IBMOSVS2
...ØØ°&...Ø&..QS.
0030ENDTE HELLO MICK..IBMOSVS2
...ØØ°&...Ø&..QS.


As you would expect, editing a new member in an existing FB 80 CLIST data
set works fine and puts the line numbers in the right place.

Interesting stuff!

Cheers,

Mick.


On 16 November 2016 at 04:38, Edward Gould  wrote:

> > On Nov 15, 2016, at 1:16 PM, Dyck, Lionel B. (TRA) 
> wrote:
> >
> > I'm in the 255 camp and just tried a simple experiment.
> >
> > From TSO issue the Edit command:  E T(ABC) CL
> >
> > This opens the old editor on dataset t.clist member abc and after adding
> a few records and saving I checked the dcb which was VB,255,3120
> >
> > Not the ideal blksize but the lrecl is what I expected.
> >
> > hth
> >
>
> Lionel:
>
> At least in mvs 3.8 there was a sysgen macro you could specify FB VB and
> lrecl blksize etc.
> Since system dissapeared I am not sure what the defaults are now days.
>
> Ed
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Kind of COND in a CLIST

[Mick Graley]

Also if you were to create a CLIST for this as suggested previously,
rather than adding lots of IFs or WHENs, you should just be able to
specify CONTROL FLUSH once at the beginning of the CLIST.

Mick.


On 21 July 2016 at 14:24, Norbert Friemel  wrote:
> On Thu, 21 Jul 2016 14:36:30 +0200, R.S. wrote:
>
>> I'm going to submit huge command list in a batch (IKJEFT01). The
>> commands are unrelated (no loops, etc.) however I want to stop the
>> script after command failure, that means RC<>0.
>>
>> Example:
>> //STEP1   EXEC PGM=IKJEFT01
>> //SYSTSPRT DD  SYSOUT=*
>> //SYSTSIN  DD  *,DLM=@@
>> /* command list */
>> RDEF class PROFILE1.** ...
>> RDEF class PROFILE2.** ...
>
> Replace IKJEFT01 with IKJEFT1A (or IKJEFT1B)?
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ikjc200/jcl_exec.htm
>
> Norbert Friemel
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TSO receive on MultiVolume PS error

[Mick Graley]

Yes XMIT definitely supports DSORG=PS RECFM=U data sets.
Good example being DFDSS dumps.
I regularly use DFDSS to dump multiple data sets, then XMIT that dump
data set to get a very portable RECFM=FB LRECL=80 version of the dump.
Cheers,
Mick.


On 20 May 2016 at 18:36, Jesse 1 Robinson  wrote:
> OP referred to a 'PS with Fo[r]mat U'. Does XMIT/RECEIVE even support PS 
> files with RECFM U? The only RECFM U files I know of are load modules, but 
> they are PO, not PS. In any case the error message refers to the XMITted 
> file, not the target.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Paul Gilmartin
> Sent: Friday, May 20, 2016 9:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: TSO receive on MultiVolume PS error
>
> On Fri, 20 May 2016 06:14:44 -0500, Elardus Engelbrecht wrote:
>>
>>Are you sure your dataset has been transferred properly and fully and without 
>>errors before you tried out RECEIVE?
>>
> My quick check for this is (IIRC):
>
> cp -B "//'DSN(MEMBER)'" /dev/fd/1 | cksum
>
> ... at both ends of the transfer and compare the checksums and lengths.
>
> (Or you could write an assembler program using CSNBOWH.)
>
> -- gil
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [SURVEY] What ISPF terminal model do you use

[Mick Graley]

Hi All,

At my old employers we used Eicon Aviva for terminal emulation and it
was quite good, I liked it, lots of customization possible and it was
fast. At my current employer we use Microfocus Rumba and I'm not very
impressed with it! At home I've used X3270 on Linux and WC3270 on
Windows to connect to Hercules and they're both OK for the price ;-)

Back to the original question though, I like to use a model 2 for
editing code (big beefy font and most code is card image anyway) and a
model 5 for SDSF. I used to use different MAI sessions with different
user IDs and logmodes to achieve this from one terminal session set up
as a model 5. It was a bit of a pain switching between the different
sessions rather than just using one ISPF session with split screen (I
always have logical screen 1 as workplace and logical screen 2 as
SDSF, then various other logical screens for DB2, BMC, extra edit
sessions etc).

I hate using a model 5 with edit on one screen and SDSF on the other
as ISPF "windows" the 80 byte edit screen into the 132 chars and it
looks horrible for editing code.

I never have the split line showing so I always get a full logical screen.

I wish IBM would enhance ISPF so that it would set the screen mode to
80x24 when I swap to my edit screen and back to 132x27 when I swap
back to SDSF. I don't see that being too big a deal if you're not
actually showing 2 logical screens with a split line on the one
terminal emulator window.

Any thoughts?

Cheers,

Mick.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [SURVEY] What ISPF terminal model do you use

[Mick Graley]

No. That's what I've got set.
Cheers,
Mick.


On 18 March 2016 at 18:09, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Fri, 18 Mar 2016 17:47:38 +0000, Mick Graley wrote:
>>
>>I wish IBM would enhance ISPF so that it would set the screen mode to
>>80x24 when I swap to my edit screen and back to 132x27 when I swap
>>back to SDSF. I don't see that being too big a deal if you're not
>>actually showing 2 logical screens with a split line on the one
>>terminal emulator window.
>>
> Can't that be selected as DATA mode?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CeBIT and mainframes

[Mick Graley]

Nah, not letting him off that easily!
The word "coded" is the same in both languages, and BCD ¬= BSD.
Like us Brits tend to say "kicks" and the Americans tend to say "see,
eye, see, ess" but it's still actually CICS :-)
Cheers,
Mick.


On 18 March 2016 at 18:35, Tom Brennan  wrote:
> Maybe EBSDIC is just like colour vs. color, spanner vs. wrench.
>
> John McKown wrote:
>>
>> I just read the article. Interestin, but, really, EBSDIC? Twice?!?
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN