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:[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
