Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
On Tue, 29 Sep 2020 16:59:34 -0700, Charles Mills wrote: >Applications should not "validate" filenames before attempting to open or >create a file. Present the name to the file system API and report any error >back to the user. Application filename validation is what leads to these >inconsistencies. > I'll emphasize that. Applications and UIs should not modify filenames -- add blanks; remove blanks; change case, etc. A related problem arose a while ago when the requirement (possibly delusional) for mixed-case passwords appeared. Many applications which though they were doing a users a favor by converting passwords to upper case had to be modified. The operation should always have been left to the security product. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
Applications should not "validate" filenames before attempting to open or create a file. Present the name to the file system API and report any error back to the user. Application filename validation is what leads to these inconsistencies. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, September 29, 2020 3:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets? On Tue, 29 Sep 2020 21:28:26 +, Pommier, Rex wrote: > >Serious question - what would be the purpose for doing this? I know you can, >I'm just trying to grasp a good reason for doing so. Security by obscurity >(not valid in my mind)? > Because it's possible. Someone will do it. Test suites should verify that other components support it properly. The security needn't be by obscurity. The security product or ACLs could enforce chosen rules. To minimize programmer astonishment the syntax and semantics should be uniform throughout the system. I have a couple experiences older than OMVS. I used ISPF LM services to create some PDS members with hyphens in their names, e.g. FOO-BAR. Subsequently I decided to add ISPF statistics to such members with LMMSTATS. LMMSTATS deems the hyphen a syntax error. Similarly, I once created a data set such as: DD DISP=(NEW,CATLG),DSN=hlq.X.FOO-BAR No problem. Later, I tried DD DISP=(NEW,CATLG),DSN=hlq.Y.FOO-BAR, DCB=hlq.X.FOO-BAR Again, the hyphen caused a syntax error. The restriction is documented, but why not be uniform? As long as STOW and BLDL have existed they have supported mixed-case member names. But most high-level user interfaces aren't even case-insensitive: they don't find any member name containing lower case characters. An IBM employee has said on this list that those names are invalid. But why doesn't STOW report them as errors. I disagree with Emerson about consistency. > > >Alas, the padding and stripping mean that 'WOMBAT', 'WOMBAT ', and 'WOMBAT >', >distinct UNIX files, would be conflated. -- 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: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
On Tue, 29 Sep 2020 21:28:26 +, Pommier, Rex wrote: > >Serious question - what would be the purpose for doing this? I know you can, >I'm just trying to grasp a good reason for doing so. Security by obscurity >(not valid in my mind)? > Because it's possible. Someone will do it. Test suites should verify that other components support it properly. The security needn't be by obscurity. The security product or ACLs could enforce chosen rules. To minimize programmer astonishment the syntax and semantics should be uniform throughout the system. I have a couple experiences older than OMVS. I used ISPF LM services to create some PDS members with hyphens in their names, e.g. FOO-BAR. Subsequently I decided to add ISPF statistics to such members with LMMSTATS. LMMSTATS deems the hyphen a syntax error. Similarly, I once created a data set such as: DD DISP=(NEW,CATLG),DSN=hlq.X.FOO-BAR No problem. Later, I tried DD DISP=(NEW,CATLG),DSN=hlq.Y.FOO-BAR, DCB=hlq.X.FOO-BAR Again, the hyphen caused a syntax error. The restriction is documented, but why not be uniform? As long as STOW and BLDL have existed they have supported mixed-case member names. But most high-level user interfaces aren't even case-insensitive: they don't find any member name containing lower case characters. An IBM employee has said on this list that those names are invalid. But why doesn't STOW report them as errors. I disagree with Emerson about consistency. > > >Alas, the padding and stripping mean that 'WOMBAT', 'WOMBAT ', and 'WOMBAT >', >distinct UNIX files, would be conflated. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
Gil, Serious question - what would be the purpose for doing this? I know you can, I'm just trying to grasp a good reason for doing so. Security by obscurity (not valid in my mind)? Thanks, Rex Alas, the padding and stripping mean that 'WOMBAT', 'WOMBAT ', and 'WOMBAT ', distinct UNIX files, would be conflated. -- gil The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASMA500W using _boundary_ on ORG statement
On Sep 29, 2020, at 3:51 PM, Seymour J Metz wrote: > > It looks like HLASM is giving the wrong error message; the syntax diagram for > ORG shows the boundary as valid only if it follows a relocatable expression. > Thanks, that was it. -- Pew, Curtis G curtis@austin.utexas.edu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASMA500W using _boundary_ on ORG statement
Agreed on the wrong message. I think ORG *,8 is what you want. And it should work regardless of SECTALGN & GOFF. btw, I'd never run across this before, so thanks for the tip. I've had one of those wacky padding-to-a-boundary macros for years, but this might be much better. Assuming it works. sas On Tue, Sep 29, 2020 at 4:51 PM Seymour J Metz wrote: > It looks like HLASM is giving the wrong error message; the syntax diagram > for ORG shows the boundary as valid only if it follows a relocatable > expression. > ... > 405+ ORG ,8 > ** ASMA500W Requested alignment exceeds section alignment > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Rapid Containers: zCX Performance Improvements
If you're interested in improving the performance of your zCX instances, you should check out the latest article in IBM Systems Magazine. There are a number of zCX APARs that are now available. For those that are running zCX in z/OS under z/VM, the Large Pages APAR offers a significant performance boost when used with 1M memory pages. https://ibmsystemsmag.com/IBM-Z/9/2020/rapid-containers-zcx -- Anthony Giorgio z/OS Container Extensions Email: agior...@us.ibm.com Twitter: https://twitter.com/a_giorgio -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASMA500W using _boundary_ on ORG statement
It looks like HLASM is giving the wrong error message; the syntax diagram for ORG shows the boundary as valid only if it follows a relocatable expression. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Pew, Curtis G Sent: Tuesday, September 29, 2020 4:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ASMA500W using _boundary_ on ORG statement I’m trying to use the _boundary_ parameter on an assembler ORG statement, and I keep getting ASMA500W errors. I’ve specified GOFF and SECTALGN(4096): 1 High Level Assembler Option Summary (PTF UI62194) Page1 - HLASM R6.0 2020/09/29 14.55 0 No Overriding ASMAOPT Parameters Overriding Parameters- ESD,RXREF,MXREF,RLD,XREF(SHORT,UNREFS),DXREF,LIST(MAX),TERM,ASA,LC(58),GOFF,SECTALGN(4096),OBJ ECT No Process Statements Options for this Assembly 0NOADATA … 3 PARM/OPTION GOFF(NOADATA) … 3 PARM/OPTION SECTALGN(4096) However, when I try to set a boundary on an ORG statement: 405+ ORG ,8 ** ASMA500W Requested alignment exceeds section alignment The last time I checked, 8 did not exceed 4096. Anyone have any suggestions about what I’m doing wrong? -- Pew, Curtis G curtis@austin.utexas.edu -- 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: [External] LMINIT cannot handle concatenation with more than 16 data sets?
No wild cards, but it does support retrieving a complete member list for the concatenation. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, September 29, 2020 4:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] LMINIT cannot handle concatenation with more than 16 data sets? On Tue, 29 Sep 2020 19:48:31 +, Seymour J Metz wrote: >Broken As Designed (BAD). It actually takes less code to do it right than to >do it wrong with the current level of DFSMSdfp, although the broken code >already exists. RFE? DESERV? Does DESERV support wildcards, needed by ISRDDN? I don't see that in the doc. On Mon, 28 Sep 2020 20:15:43 +, Pommier, Rex wrote: > >..., but when I enter ISRDDN and try to browse a library concatenation >with greater than 16 libraries in it, ... Does DESERV support UNIX directories? This is tantalizing: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/d4280.htm Each name is comprised of a two-byte length field followed by the characters of the name. When searching for names with less than eight characters, the names are padded on the right with blanks to make up eight characters. Names greater than eight characters will have trailing blanks and nulls stripped (to a minimum length of eight) before the search. What, other than UNIX files would have "[n]ames greater than eight characters"? Alas, the padding and stripping mean that 'WOMBAT', 'WOMBAT ', and 'WOMBAT ', distinct UNIX files, would be conflated. LMINIT refuses UNIX files. Something about F1 DSCB. Why? -- 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: [External] LMINIT cannot handle concatenation with more than 16 data sets?
On Tue, 29 Sep 2020 19:48:31 +, Seymour J Metz wrote: >Broken As Designed (BAD). It actually takes less code to do it right than to >do it wrong with the current level of DFSMSdfp, although the broken code >already exists. RFE? DESERV? Does DESERV support wildcards, needed by ISRDDN? I don't see that in the doc. On Mon, 28 Sep 2020 20:15:43 +, Pommier, Rex wrote: > >..., but when I enter ISRDDN and try to browse a library concatenation >with greater than 16 libraries in it, ... Does DESERV support UNIX directories? This is tantalizing: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/d4280.htm Each name is comprised of a two-byte length field followed by the characters of the name. When searching for names with less than eight characters, the names are padded on the right with blanks to make up eight characters. Names greater than eight characters will have trailing blanks and nulls stripped (to a minimum length of eight) before the search. What, other than UNIX files would have "[n]ames greater than eight characters"? Alas, the padding and stripping mean that 'WOMBAT', 'WOMBAT ', and 'WOMBAT ', distinct UNIX files, would be conflated. LMINIT refuses UNIX files. Something about F1 DSCB. Why? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ASMA500W using _boundary_ on ORG statement
I’m trying to use the _boundary_ parameter on an assembler ORG statement, and I keep getting ASMA500W errors. I’ve specified GOFF and SECTALGN(4096): 1 High Level Assembler Option Summary (PTF UI62194) Page1 - HLASM R6.0 2020/09/29 14.55 0 No Overriding ASMAOPT Parameters Overriding Parameters- ESD,RXREF,MXREF,RLD,XREF(SHORT,UNREFS),DXREF,LIST(MAX),TERM,ASA,LC(58),GOFF,SECTALGN(4096),OBJ ECT No Process Statements Options for this Assembly 0NOADATA … 3 PARM/OPTION GOFF(NOADATA) … 3 PARM/OPTION SECTALGN(4096) However, when I try to set a boundary on an ORG statement: 405+ ORG ,8 ** ASMA500W Requested alignment exceeds section alignment The last time I checked, 8 did not exceed 4096. Anyone have any suggestions about what I’m doing wrong? -- Pew, Curtis G curtis@austin.utexas.edu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] LMINIT cannot handle concatenation with more than 16 data sets?
Broken As Designed (BAD). It actually takes less code to do it right than to do it wrong with the current level of DFSMSdfp, although the broken code already exists. RFE? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Monday, September 28, 2020 9:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] LMINIT cannot handle concatenation with more than 16 data sets? On Mon, 28 Sep 2020 20:15:43 +, Pommier, Rex wrote: >Robert, > >IDK if this specifically LMMINIT, but when I enter ISRDDN and try to browse a >library concatenation with greater than 16 libraries in it, I get this: > >Only the first sixteen data sets are shown in this list. ISRDDN uses ISPF >services to process DD names and these services are limited to >concatenations of sixteen or fewer data sets. > >Whichleeads me to believe the 16 limit is still there. z/OS 2.4. > Perhaps worse, it does not report members in UNIX files in directories among the 16 supported catenands. So if I have member WOMBAT in a zFS in a SYSLIB concatenation, it may show me a WOMBAT in a later PDS(E) whereas HLASM will use the one in the zFS. Treacherous indeed. I suspect that ISPF uses the antique technique of allocating each catenand with DSORG=PS and parsing directory blocks. Would DESERV do better? I went to SR on this: Record 55733,033,000 Created:04/11/22 ... got an elaborate WAD. -- 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: Working link for current 3270 Data Stream
I am running IBMs Book Reader under CrossOver under Linux. Book Reader does not really have a 'Print all of the book' option. Tony Thigpen Paul Gilmartin wrote on 9/29/20 12:40 PM: On Tue, 29 Sep 2020 12:23:29 -0400, Tony Harminc wrote: On Mon, 28 Sep 2020 at 16:12, Tony Thigpen wrote: FYI, I do have a copy of GA23-0059-07 in PDF format that I created from the BOO sometime in the past. If anyone wants a copy. How did you convert it? I'm not aware of any IBM published tool to do that. Print-to-PDF is intrinsic on some systems such as MacOS, perhaps optional via virtual printer drivers on others. But does Document Reader prohibit all printing with the intent of IP protection? --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: Working link for current 3270 Data Stream
On Tue, 29 Sep 2020 12:23:29 -0400, Tony Harminc wrote: >On Mon, 28 Sep 2020 at 16:12, Tony Thigpen wrote: > >> FYI, I do have a copy of GA23-0059-07 in PDF format that I created from >> the BOO sometime in the past. If anyone wants a copy. > >How did you convert it? I'm not aware of any IBM published tool to do that. > Print-to-PDF is intrinsic on some systems such as MacOS, perhaps optional via virtual printer drivers on others. But does Document Reader prohibit all printing with the intent of IP protection? --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Working link for current 3270 Data Stream
There used to be a web tool at: http://ps-2.kev009.com/boo2pdf/ He has discontinued the web service, but does provide links if you want to install something on your computer. Tony Thigpen Tony Harminc wrote on 9/29/20 12:23 PM: On Mon, 28 Sep 2020 at 16:12, Tony Thigpen wrote: FYI, I do have a copy of GA23-0059-07 in PDF format that I created from the BOO sometime in the past. If anyone wants a copy. How did you convert it? I'm not aware of any IBM published tool to do that. Tony H. -- 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: Working link for current 3270 Data Stream
On Mon, 28 Sep 2020 at 16:12, Tony Thigpen wrote: > FYI, I do have a copy of GA23-0059-07 in PDF format that I created from > the BOO sometime in the past. If anyone wants a copy. > How did you convert it? I'm not aware of any IBM published tool to do that. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS,Version 2 Release 4,Language Environment,Programming Reference - ceea300_v2r4.pdf
I pointed the content developer for this information to this discussion in case any changes are needed. Thanks! -Sue Shumway On 9/29/2020 9:29 AM, Hayim Sokolsky wrote: Switzerland:French, German, Italian, and Romansh. On Sep 29, 2020, at 09:24, R.S. wrote: W dniu 29.09.2020 o 00:54, Robert Prins pisze: Just had a look at https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosv2r4sa380683/$file/ceea300_v2r4.pdf?OpenElement&xpdflink to find a country code that gives me dates in ISO8601 format (why isn't there a simple "LANGUAGE(my-country(ISO))" option to use a specific currency, but ISO8601 dates/times? RFE?), and I was flabbergasted to see that (at least in this PDF) Lithuania, Latvia, Estonia, Cyprus, Slovakia are still using currencies that no longer exist, and that Montenegro & Serbia (and probably a few more countries) don't even seem to exists. Robert First question: I guess ISO would be ambigous, as there are many ISO standards which may be considered here. BTW: despite of errors/outdated informations - things may be more complicated than "one country, one answer". Serbia have two very different code pages - one for cyrillic, one latin. In Poland we have latin only, but wide set of codepages: CP 870 for EBCDIC, CP852 for PCDOS, CP1250 for Windows, ISO8850-2 for Unix and Internet-related things. That are in wide use today, however we had much more, like Mazovia, PESEL, DHN, Świerk, Kajkowski, etc. Note, the table does not mention only current values, but also some historical ones - like USSR and ruble, two german countries, Czechoslovakia, etc. Of course there is no more Czechoslovakia, and Slovakia has Euro currency (and my bank was first which finished conversion from former corona). And there are of course countries have more than one language. For example Switzerland has four languages (who know what is the fourth one?), but US has no official language. ;-) And or course there are timezones - US have many timezones, but even countries within same, single timezone may have different regulations related to DST. BTW: as far as I know UE decided to get rid of DST, but each country has to decide which time they will use. A lot of curiosities. -- Radoslaw Skorupka Lodz, Poland -- 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 -- Sue Shumway z/OS Project Lead and Client Advocate IBM Poughkeepsie chale...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Working link for current 3270 Data Stream
Hi all, First, addressing the links on the Publications Center page: - None of the links to online versions of the BOO publications will work because the IBM-served BookManager content site was taken down years ago. (This is not an invitation to open back up the complaint department for that action!) That's unfortunate that the dead "Read" links remain to confuse folks - sorry about that. - "Download HTTP" and "Download Director" are just two different methods for downloading the same file (the .boo). As for a PDF of the 3270 Data Stream Program Reference (GA23-0059-07), I'm not finding it on any official IBM site. That doesn't mean that it doesn't exist, though - I'll keep poking around and will report back if I find it. -Sue Shumway On 9/29/2020 9:49 AM, Styles, Andy , ITS zPlatform Services wrote: Classification: Limited There appears to be a GA23-0059-7 here: http://www.ruelgnoj.co.uk/3270/3270.pdf Whether that's Tony's one, I don't know, but it looks like it came from Bookmanager - I can't access it from my work laptop, but it looks okay on my phone. Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: 29 September 2020 14:15 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Working link for current 3270 Data Stream -- This email has reached the Bank via an external source -- Yeah, but it's not the latest one. On 2020-09-29 09:05, Wendell Lovewell wrote: GA23-0059-4 is already on Bitsavers: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbitsa vers.trailing-edge.com%2Fpdf%2Fibm%2F3270%2FGA23-0059-4_3270_Data_Stre am_Programmers_Reference_Dec88.pdf&data=02%7C01%7CAndy.Styles%40Ll oydsBanking.com%7Ce215590750d64a0e82bd08d86479c1cd%7C3ded2960214a46ff8 cf4611f125e2398%7C0%7C0%7C637369821388915261&sdata=9uSdmXPpETVZncU u1jnFw%2F1uYSa9MXESAEVpLn0TKrE%3D&reserved=0 -- 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 Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Scottish Widows Schroder Personal Wealth Limited. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 11722983. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Scottish Widows Schroder Personal Wealth Limited is authorised and regulated by the Financial Conduct Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Sue Shumway z/OS Project Lead and Client Advocate IBM Poughkeepsie chale...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS support for ZFS files query
On Tue, 29 Sep 2020 08:52:38 +0100, Sean Gleann wrote: >I'm currently investigating the use of DFDSS DUMP PATH to secure data held >in UNIX files and folders. >... >"DFSMSdss does not provide wildcard support when processing UNIX files." >... >I can see a possible method of including a massaged version of 'ls' output >in the INCLUDE parameter, but I don't see this as a particularly workable >solution. > The better utility for that is "find" rather than "ls". "find" supports wildcards and boolean expressions; "ls" supports neither. The massaging would need to protect special characters with a scheme supported by DFSMSdss. Filenames containing NL are a particular challenge. ALas, z/OS's "find" does not support the precious "-print0" extension. What you're asking is akin to asking DFSMSdss to select individual PDS members. >Also, with a DUMP of data comes the requirement to be able to RESTORE it to >- possibly - a different WORKINGDIRECTORY, but I haven't got that far yet. > Use 'pax". Mr. Natural sez, Use the right tool for the job. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Working link for current 3270 Data Stream
Classification: Limited There appears to be a GA23-0059-7 here: http://www.ruelgnoj.co.uk/3270/3270.pdf Whether that's Tony's one, I don't know, but it looks like it came from Bookmanager - I can't access it from my work laptop, but it looks okay on my phone. Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: 29 September 2020 14:15 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Working link for current 3270 Data Stream -- This email has reached the Bank via an external source -- Yeah, but it's not the latest one. On 2020-09-29 09:05, Wendell Lovewell wrote: > GA23-0059-4 is already on Bitsavers: > https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbitsa > vers.trailing-edge.com%2Fpdf%2Fibm%2F3270%2FGA23-0059-4_3270_Data_Stre > am_Programmers_Reference_Dec88.pdf&data=02%7C01%7CAndy.Styles%40Ll > oydsBanking.com%7Ce215590750d64a0e82bd08d86479c1cd%7C3ded2960214a46ff8 > cf4611f125e2398%7C0%7C0%7C637369821388915261&sdata=9uSdmXPpETVZncU > u1jnFw%2F1uYSa9MXESAEVpLn0TKrE%3D&reserved=0 > > -- > 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 Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Scottish Widows Schroder Personal Wealth Limited. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 11722983. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Scottish Widows Schroder Personal Wealth Limited is authorised and regulated by the Financial Conduct Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Working link for current 3270 Data Stream
W dniu 29.09.2020 o 05:33, Lizette Koehler pisze: You need to be careful about copyrights and uploading to something other than an IBM approved site. Just saying. Formally, yes. Really, not so. I think all or vast majority of bitsavers content is copyrighted material. But it is kind of abandonware - copyrighted thing which provide no profit, no chance for profit and the owner is: a) no longer interested about this thing b) the owner disappeared c) it is not clear who is the owner today. Note, bitsavers contain a lot of material which were never ever been available to public, especially those printed manuals usually were available to customers and sometime manuals were paid. Here we have something which is copyrighted, but still available to anyone. BTW: I wish IBM would give all the old stuff previously available on their pages to some organization like wikipedia, bitsavers or other, or all of them. We would still have access to bookreader books regarding OS/390 or MVS, as well as VSE, VM, etc. -- Radoslaw Skorupka Lodz, Poland == 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.2020 r. wynosi 169.401.468 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.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS,Version 2 Release 4,Language Environment,Programming Reference - ceea300_v2r4.pdf
Switzerland:French, German, Italian, and Romansh. > On Sep 29, 2020, at 09:24, R.S. wrote: > > W dniu 29.09.2020 o 00:54, Robert Prins pisze: >> Just had a look at >> https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosv2r4sa380683/$file/ceea300_v2r4.pdf?OpenElement&xpdflink >> to find a country code that gives me dates in ISO8601 format (why isn't >> there a simple "LANGUAGE(my-country(ISO))" option to use a specific >> currency, but ISO8601 dates/times? RFE?), >> >> and >> >> I was flabbergasted to see that (at least in this PDF) Lithuania, Latvia, >> Estonia, Cyprus, Slovakia are still using currencies that no longer exist, >> and that Montenegro & Serbia (and probably a few more countries) don't even >> seem to exists. >> >> Robert > > First question: I guess ISO would be ambigous, as there are many ISO > standards which may be considered here. > > BTW: despite of errors/outdated informations - things may be more complicated > than "one country, one answer". Serbia have two very different code pages - > one for cyrillic, one latin. > In Poland we have latin only, but wide set of codepages: CP 870 for EBCDIC, > CP852 for PCDOS, CP1250 for Windows, ISO8850-2 for Unix and Internet-related > things. That are in wide use today, however we had much more, like Mazovia, > PESEL, DHN, Świerk, Kajkowski, etc. > Note, the table does not mention only current values, but also some > historical ones - like USSR and ruble, two german countries, Czechoslovakia, > etc. > Of course there is no more Czechoslovakia, and Slovakia has Euro currency > (and my bank was first which finished conversion from former corona). > And there are of course countries have more than one language. For example > Switzerland has four languages (who know what is the fourth one?), but US has > no official language. ;-) > And or course there are timezones - US have many timezones, but even > countries within same, single timezone may have different regulations related > to DST. > BTW: as far as I know UE decided to get rid of DST, but each country has to > decide which time they will use. > A lot of curiosities. > > > -- > Radoslaw Skorupka > Lodz, Poland > > > -- > 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,Version 2 Release 4,Language Environment,Programming Reference - ceea300_v2r4.pdf
W dniu 29.09.2020 o 00:54, Robert Prins pisze: Just had a look at https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosv2r4sa380683/$file/ceea300_v2r4.pdf?OpenElement&xpdflink to find a country code that gives me dates in ISO8601 format (why isn't there a simple "LANGUAGE(my-country(ISO))" option to use a specific currency, but ISO8601 dates/times? RFE?), and I was flabbergasted to see that (at least in this PDF) Lithuania, Latvia, Estonia, Cyprus, Slovakia are still using currencies that no longer exist, and that Montenegro & Serbia (and probably a few more countries) don't even seem to exists. Robert First question: I guess ISO would be ambigous, as there are many ISO standards which may be considered here. BTW: despite of errors/outdated informations - things may be more complicated than "one country, one answer". Serbia have two very different code pages - one for cyrillic, one latin. In Poland we have latin only, but wide set of codepages: CP 870 for EBCDIC, CP852 for PCDOS, CP1250 for Windows, ISO8850-2 for Unix and Internet-related things. That are in wide use today, however we had much more, like Mazovia, PESEL, DHN, Świerk, Kajkowski, etc. Note, the table does not mention only current values, but also some historical ones - like USSR and ruble, two german countries, Czechoslovakia, etc. Of course there is no more Czechoslovakia, and Slovakia has Euro currency (and my bank was first which finished conversion from former corona). And there are of course countries have more than one language. For example Switzerland has four languages (who know what is the fourth one?), but US has no official language. ;-) And or course there are timezones - US have many timezones, but even countries within same, single timezone may have different regulations related to DST. BTW: as far as I know UE decided to get rid of DST, but each country has to decide which time they will use. A lot of curiosities. -- Radoslaw Skorupka Lodz, Poland == 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.2020 r. wynosi 169.401.468 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.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Working link for current 3270 Data Stream
Yeah, but it's not the latest one. On 2020-09-29 09:05, Wendell Lovewell wrote: GA23-0059-4 is already on Bitsavers: https://eur06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fibm%2F3270%2FGA23-0059-4_3270_Data_Stream_Programmers_Reference_Dec88.pdf&data=02%7C01%7C%7Cbb7567d9d7814551292208d8647855be%7C84df9e7fe9f640afb435%7C1%7C0%7C637369815298845667&sdata=MJHsTfV%2BqFlplSapgWpmCm11qEUSt3uRQHCTep3GxPY%3D&reserved=0 -- 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: Working link for current 3270 Data Stream
My original message mentioned that and asked, as does the subject, for a link to the current edition, which is -7 or later. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Wendell Lovewell <01e9c0ee0673-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, September 29, 2020 9:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Working link for current 3270 Data Stream GA23-0059-4 is already on Bitsavers: http://secure-web.cisco.com/1-Wr4wywS5OObwEhLYXVxt8QeooJUaOz4raEMIWBZ3MLW_3cy3qi80-Z01Y5liBgoWPs7vs-_SVB_GfxUmsoYTIFnGYZA3FamFPwt0bHlqV08QJCmimdrwJGOykfBEe8XLaRy8cctTIhjJl8SqiOJ_Z_WPLAYf_PGlbioTauPLsdlrgO0gd_RElq3rTVktKm22g8uhW-PvedqW16tIyh8zn_LojxRDX33v30_MYxuwrq4VAFk_xpqC5YdaUEpQj7dGUXzr4elFh5rsFLl-p5K6DRn7j_YyE_V4TJkEp-TLXS0mC0eduIJLthbZu3RWnucq8kTiDqs49jnLY22yZzYcia9F1jGD4ftIYkxFscNXI3PEZIynCRzBf-oAMGbmuSzY8YbzkOvm4GZQarwoMtPSfAjCk8gJQRD5fEyhcIvfGBW4Hlc166Sh3O4mTEIQx_n/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fibm%2F3270%2FGA23-0059-4_3270_Data_Stream_Programmers_Reference_Dec88.pdf -- 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: Working link for current 3270 Data Stream
GA23-0059-4 is already on Bitsavers: http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA23-0059-4_3270_Data_Stream_Programmers_Reference_Dec88.pdf -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
NVAS MVS 2.1 help
Hello Group Is anyone still using NVAS 2.1 ? We have got a system where NVAS is not being used for long and I want make it work. As per the manual PUBUSER can logon without a password but it doesn't do that way. Is there a way to disable logon exit using AMASZAP and allow PUBUSER to logon without a password ? How do we enable RACF interface with NVAS so that any user can login using Mainframe password ? Any pointers are much appreciated Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTPS Handshake Error
You can look up RC 428 in the System SSL return codes manual. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.gska100/id428.htm Return codes in the 5xxx range are from AT-TLS and in the Comms Server manuals. System SSL 428 means that the owner of the certificate does not have access to the private key. Make sure the keyring and certificate have the correct owner userid. Check the keyring has the expected certificate and the CA(s) that signed it. You may or may not need a client certificate. If you have configured the FTP server to authenticate by mapping the client certificate to a userid you do need the client certificate. This is mutual authentication. If you are not using the client certificate for user authentication it is not needed. Mike Wawiorko -Original Message- From: IBM Mainframe Discussion List On Behalf Of Roberto Halais Sent: 28 September 2020 15:21 To: IBM-MAIN@LISTSERV.UA.EDU Subject: FTPS Handshake Error This message originated from outside our organisation and is from web based email - roberto.hal...@gmail.com Listers: I am a bit stumped with this syslog error message at the server side of an ftps connection: EZD1285I TTLS Data CONNID: 06D2A8A0 RECV CIPHER 160303008F EZD1285I TTLS Data CONNID: 06D2A8A0 RECV CIPHER 018B03035F71E9D266E9EBC723DE2DE3C4FC1E352E22A9E403C2CEADC2B74B5C158F8A60 EZD1285I TTLS Data CONNID: 06D2A8A0 SEND CIPHER 15030300020250 EZD1284I TTLS Flow GRPID: 0006 ENVID: 001D CONNID: 06D2A8A0 *RC: 428* Call GSK_SECURE_SOCKET_INIT - 005011424E50 EZD1283I TTLS Event GRPID: 0006 ENVID: 001D CONNID: 06D2A8A0 *RC: 428* Initial Handshake 005011421A1 We are doing a FTPS from one client lpar to a server lpar. We coded our policy agent rules and ftp client/server parameters. We created a CA certificate and a user certificate signed by the CA. The ftps stc owner is the same owner of the keyring. The lpars share the same Top Secret environment so both lpars see the same keyring. In the policy agent rules do we have to specify the certificate labels or will it just use the DEFAULT certificate specified in the keyring? We have debugged many errors but this one has proven a challenge for us. Any documentation or policy agent samples that you can lead me to will be appreciated. Thank you. Roberto -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Execution Services Limited provides support and administrative services across Barclays group. Barclays Execution Services Limited is an appointed representative of Barclays Bank UK plc, Barclays Bank plc and Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays Bank plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Clydesdale Financial Services Limited is authorised and regulated by the Financial Conduct Authority. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS support for ZFS files query
It appears that you have to specify the paths as separate include statements. I would use a USS REXX script using readdir and build the include statements. I've done something similar to chase file names down from a starting directory to build a second shell script for a bunch of sed commands. On Tue, Sep 29, 2020 at 5:53 PM Sean Gleann wrote: > I'm currently investigating the use of DFDSS DUMP PATH to secure data held > in UNIX files and folders. > > As far as I can see, I have to specify the WORKINGDIRECTORY to establish > the starting point for the DUMP operation, then use INCLUDE to _explicitly_ > specify the files I want. The available documentation states: > "DFSMSdss does not provide wildcard support when processing UNIX files." > which, for my purposes, is a complete show-stopper. > > The subject UNIX folder contain many hundreds, perhaps thousands, of > individual files and sub-folders (and sub-sub-folders, etc). What I want to > do is to dump the complete contents of a UNIX folder in a way analogous to > dumping all z/OS files with a common set of HLQs. > > I can see a possible method of including a massaged version of 'ls' output > in the INCLUDE parameter, but I don't see this as a particularly workable > solution. > > Am I reading things wrongly and missing a vital point here? Does anyone > know if wildcard support is something that will be made available in the > future? > > Also, with a DUMP of data comes the requirement to be able to RESTORE it to > - possibly - a different WORKINGDIRECTORY, but I haven't got that far yet. > > Regards > Sean > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DFDSS support for ZFS files query
I'm currently investigating the use of DFDSS DUMP PATH to secure data held in UNIX files and folders. As far as I can see, I have to specify the WORKINGDIRECTORY to establish the starting point for the DUMP operation, then use INCLUDE to _explicitly_ specify the files I want. The available documentation states: "DFSMSdss does not provide wildcard support when processing UNIX files." which, for my purposes, is a complete show-stopper. The subject UNIX folder contain many hundreds, perhaps thousands, of individual files and sub-folders (and sub-sub-folders, etc). What I want to do is to dump the complete contents of a UNIX folder in a way analogous to dumping all z/OS files with a common set of HLQs. I can see a possible method of including a massaged version of 'ls' output in the INCLUDE parameter, but I don't see this as a particularly workable solution. Am I reading things wrongly and missing a vital point here? Does anyone know if wildcard support is something that will be made available in the future? Also, with a DUMP of data comes the requirement to be able to RESTORE it to - possibly - a different WORKINGDIRECTORY, but I haven't got that far yet. Regards Sean -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
