Don:

As someone else stated they have since fixed this issue.
I wonder when, though.
My memory is iffy here though I think the TMC is unmoveable (although to me it shouldn't be under SMS control) but that does beg the point with other vendors who still use unmoveable datasets. I don't think IBM advises putting HSM (as well as other) system type data under SMS. Its been a while since I have cared but packs like JES2 (3) Spool, checkpoint would be a waste of effort to use SMS to control them. I "like" the idea of SMS but there should be different exceptions for system type datasets especially datasets that that are not really opened
Ed
On Jan 10, 2013, at 9:02 AM, Don Williams wrote:

Ed:

We still have SAS although the excessive $$ is making my manager think about
alternatives.
I think SAS may be finally trying to comply. For example, SAS 9.2 finally
supports DSNTYPE=LARGE.

Don

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM- [email protected]] On
Behalf Of Ed Gould
Sent: Wednesday, January 09, 2013 11:46 PM
To: [email protected]
Subject: Re: ESDS extent ...

Don:

Sorry to say that there are still (to this day) datasets (SAS) comes to
mind.
I (Long ago) opened a problem with them asking that they at the minimum change it to dsorg=dau (direct access unmovable) but got the stupid ass reply well it moveable if you use sas. SIGH... I gave up and did a campaign
in the company that if you used sas do not create sas db's. I got a
willingness to comply but we dropped SAS ($$ and other issues) so it really
didn't make a whole lot of difference.

Ed



On Jan 9, 2013, at 5:59 PM, Don Williams wrote:

I agree. My definition of "minor change" is a change that does not
affect the application's logical view of the file as seen through its
access methods. Some types of change might be "minor" for one
application, whereas the same type of change for a different
application would be catastrophic.
Of course, I need to understand how the application accesses its
files, in order to succesfully make these kinds of "minor changes". So
I would love it if I could use HSM recall to do that.

I can remember a stone-age application that required its master file
to be a specific size on a particular volume at specific location on
that volume.
Hopefully, all applcations like that are long dead and gone.

Nowdays, most (but not all) applications are written to be independent
of the CISZ or BLKSIZE, therefore changing the CISZ or BLKSIZE makes
no logical difference to the application. For an application that uses
standard access methods, even changing the file from non-EA to EA
should make no logical difference.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM- [email protected]]
On Behalf Of R.S.
Sent: Wednesday, January 09, 2013 5:53 PM
To: [email protected]
Subject: Re: ESDS extent ...

W dniu 2013-01-09 22:53, Don Williams pisze:
The HSM manuals do not clearly state that the objective of HSM is to
re-create the dataset as it was previously created. For example, with
the right options a HSM recall can convert a SMS-managed data set to
non-SMS-managed and vice versa (with some restrictions, of course). I
agree that some changes like making the LRECL smaller or converting
from/to EBCDIC to/from ASCII would destory data. However, HSM could
be designed to perform useful minor format changes during a recall. I
would love it, if HSM had recall options to change the primary and
secondary allocation quanities, non-EA to EA, change blksize or
cisize,
etc.

Well, it depends on definition of "minor change". ExtFmt, CISZ,
BLKSIZE are NOT minor changes in my understanding because they change
format of
*existing* data. There are aplications CISZ or BLKSIZE dependent, Ext
Fmt
*is* physically different, etc.
SMS-managed or not does not affect the data itself.


--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe
by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli
nie jeste adresatem niniejszej wiadomoci lub pracownikiem
upowanionym do jej przekazania adresatowi, informujemy, e jej
rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o
podobnym charakterze jest prawnie zabronione i moe by karalne.
Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and
is intended solely for business use of the addressee. This e-mail may
only be received by the addressee and may not be disclosed to any
third parties. If you are not the intended addressee of this e- mail or
the employee authorised to forward it to the addressee, be advised
that any dissemination, copying, distribution or any other similar
activity is legally prohibited and may be punishable. If you received
this e-mail by mistake please advise the sender immediately by using
the reply facility in your e-mail software and delete permanently this
e-mail including any copies of it either printed or saved to hard
drive.

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829
00 00,
fax +48 (22) 829 00 33, www.brebank.pl, e-mail: [email protected] Sd
Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego
Rejestru Sdowego, nr rejestru przedsibiorców KRS 0000025237, NIP:
526-021-50-88.
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w
caoci wpacony) wynosi 168.555.904 zotych.


--------------------------------------------------------------------- -
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [email protected] with the message: INFO IBM-MAIN

--------------------------------------------------------------------- -
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to