Re: load library lrecl=??
On 2018-09-06 1:41 PM, Brian Westerman wrote: Apparently some of the libraries shipped by some vendors or at least the directions to define them specify RECFM=U,LRECL=256. Maybe the vendor instruction writers looked at their data sets and copied the attributes they saw. So, I had this TSO command called REVIEW which read PDS directories using RECFM=F,LRECL=256,BLKSIZE=256 with QSAM. Years later I noticed that it seemed to be setting the LRECL of RECFM=U data sets to 256, although I maintain that it did not do that when first developed. So, with DCB attribute merging, the VTOC entry got zero fields updated from the JFCB even though it was only opened for INPUT. Or maybe I added a feature which could update the PDS, and it was on these occasions which added a non-zero LRECL to the VTOC entry. The result was that my RECFM=U data sets processed by this program ended up with LRECL=256. Whatever the actual details were that caused this update, the LRECL-changing phenomenon all went away when I removed the LRECL value from the directory-reading DCB. Looking at the source now, it says RECFM=F and BLKSIZE=256, but the "problem" as not occurred with this combo. Once the LRECL is set, it won't go away unless removed by "unnatural" means. So maybe someone used this or a similar program on their library at some stage. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: load library lrecl=??
Good, I was hoping that I wasn't missing something. It does appear to be ignored for RECFM=U. Thanks Brian On Thu, 6 Sep 2018 09:04:25 -0400, Steve Smith wrote: >LRECL has no meaning for RECFM=U as far as the system goes. It is recorded >in the DSCB, but that is all. Anyway, only QSAM ever uses LRECL for any >dataset. So there's no good reason for specifying LRECL on a load >library. It can default to 0 just fine, because it's meaningless. > >As far as directory reading goes, the DCB would need to specify DSORG, >RECFM, BLKSIZE overrides, and KEYLEN with BSAM; again LRECL is irrelevant. >For QSAM it would be needed, but letting it default to the DSCB would be >fatuous. > > >sas > >-- >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: VSAM share-option 4
Quote exactly where I said that SVS did not have VSAM. I believe you will find that it was a reader's inference because I didn't say one way or the other. I gave the order of which system got VSAM first from my memories. And I mangled a sentence -- I looked at it a few times after the posting and it wasn't clear. So with SVS being chopped liver, I decided it wasn't worth the efforts (or Shmuel, was that a bad inference by me reading what you said?). AFTER ALL, this is 2018, not the 1970s. Those things make no difference anymore. But the difference in the way it was implemented between OS and DOS made a big difference in how SHAREOPTIONS were implemented/done/used. And that is the problem the OP is having to deal with after the migration. And to another posting about SHAREOPTION 5 -- I'd be more inclined to suggest the use of IAM. Cheaper than IBM's VSAM, while doing the same types of files as VSAM and providing the cross "DOMAIN" support that the OP might need. I am probably prejudiced against a certain vendor because of experience with them putting their cash cow in their basement. It might be worth a trial to see the differences and costs. Regards, Steve Thompson On 09/06/2018 03:04 PM, Seymour J Metz wrote: Who said SVS did not have VSAM? Steve Thompson SVS certainly did have VSAM Indeed. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Mark Waterbury <01c3f560aac1-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, September 5, 2018 6:19 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: VSAM share-option 4 Who said SVS did not have VSAM? SVS certainly did have VSAM ... It was an ICR -- Independent Component Release -- so somewhat tricky to get it installed into SVS, but once installed, it did work... and CICS/VS used it ... This was on SVS 1.7 circa 1976-77... And, just like on MVS, on SVS, we were taught that: Share optionsmeans3Close your eyes4 Close your eyes and step on the gas! Does that jog anyone's memory? Mark S. Waterbury On Wednesday, September 5, 2018, 12:35:26 AM EDT, Seymour J Metz wrote: > VSAM was implemented at the OS level with DOS/VS (and IIRC, DOS/VS was first to have VSAM with MVS|VS1 to follow), where with OS (OS/VS1 or MVS) What was SVS, chopped liver? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Steve Thompson Sent: Tuesday, September 4, 2018 8:35 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: VSAM share-option 4 Yes your reading and interpretation is essentially correct. VSAM was implemented at the OS level with DOS/VS (and IIRC, DOS/VS was first to have VSAM with MVS|VS1 to follow), where with OS (OS/VS1 or MVS) it was implemented at the address space level. Whoever did your migration, if they did not have a background involving DOS/VS_ and just did a flat migration to MVS (z/OS), you can get royally shafted. The SHARE OPTIONS between the two systems are very different and one has to know and understand this to do a proper migration and Catalog structures are very different between the two systems. Where you would do backups by CATALOG, a CATALOG does not OWN the volumes in an MVS shop. But they did in a DOS/VS shop. And I hate to break this to you at this late date, but if the migrators didn't know it, the z/VSE system was an XA I/O system and so the performance increase for I/O that one expected in days of yore in going to z/OS will not be there (until DOS/VSE/ESA, DOS systems were BASE S/370 using the OLD SIO/SIOF, etc. and not SSCH and related instructions). You may actually lose performance in the z/OS environment as a result. Regards, Steve Thompson On 09/04/2018 07:42 PM, Tony Thigpen wrote: My main background is z/VSE but now I have to manage a bunch of z/OS sites, including one that recently converted from z/VSE to z/OS. On z/VSE, share-option 4 means that VSAM will prevent any read or write integrity exposures when multiple tasks are accessing the same VSAM file. z/VSE VSAM will internally lock any CI that is being updated so that nobody else can update the CI. This ENQ/DEQ is handled by the IBM provided VSAM IO routines at the task level. Additionally, VSAM will flush all update buffers after a write or update. And, it will not buffer reads when reading a share-option 4 file. (I am being somewhat general in the descriptions, so the details are a little more complicated.) All this to make sure that the records on disk and the records in buffers match. Now, with z/OS, my reading of the VSAM Demystified RedBook leads me to the following: 1) Share-option 4 allows multiple open for update, but expects the program, not the VSAM subsystem, to perform the ENQ/DEQs. 2) If a program does not perform ENQ/DEQs, then data integrity is lost as multiple tas
Re: Spectre/Meltdown APAR - OA54807
Hi Tom,
We have been running with OSPROTECT=1 for a couple months now. We ran a few
crypto and i/o oriented utilities as well as product IVPs and noticed no
performance impacts after implementation. That said we are a development shop
and don't run typical customer workloads. I would suggest running your own
bread and butter workloads in an isolated test LPAR both with and without the
maintenance if you're resource constrained in production and want to minimize
risk.
HTH,
Mike
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Phillips, Thomas
Sent: Thursday, September 6, 2018 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Spectre/Meltdown APAR - OA54807
Has anyone installed OA54807? If so, did you see any performance impacts? Any
other gotchas that you'd like to share?
Has anyone implemented OSPROTECT=1?
Thanks,
Tom Phillips
Principal Financial Group
Classification: Internal Use
-Message Disclaimer-
This e-mail message is intended only for the use of the individual or entity to
which it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law. If you are not
the intended recipient, any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by reply email to conn...@principal.com
and delete or destroy all copies of the original message and attachments
thereto. Email sent to or from the Principal Financial Group or any of its
member companies may be retained as required by law or regulation.
Nothing in this message is intended to constitute an Electronic signature for
purposes of the Uniform Electronic Transactions Act (UETA) or the Electronic
Signatures in Global and National Commerce Act ("E-Sign") unless a specific
statement to the contrary is included in this message.
If you no longer wish to receive any further solicitation from the Principal
Financial Group you may unsubscribe at
https://www.principal.com/do-not-contact-form any time.
If you are a Canadian resident and no longer wish to receive commercial
electronic messages you may unsubscribe at
https://www.principal.com/do-not-email-request-canadian-residents any time.
This message was secured by Zix(R).
--
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
Unexpected UDP sendto() errors on z/OS V2R3
I've got code that has been running unmodified "forever." It does a UDP sendto(). Those of you familiar with UDP know that the good news with UDP is that you never get errors; the bad news is that you never get errors. Suddenly, at two customers we are seeing EIO or 122 from sendto(). EIO has one of those generic "an I/O error occurred" descriptions. The common thread is they are both V2R3. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ce ea900/cs00228.htm Is anyone else seeing anything like this? Anyone have any insights? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Spectre/Meltdown APAR - OA54807
Has anyone installed OA54807? If so, did you see any performance impacts? Any
other gotchas that you'd like to share?
Has anyone implemented OSPROTECT=1?
Thanks,
Tom Phillips
Principal Financial Group
Classification: Internal Use
-Message Disclaimer-
This e-mail message is intended only for the use of the individual or entity to
which it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law. If you are not
the intended recipient, any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by reply email to conn...@principal.com
and delete or destroy all copies of the original message and attachments
thereto. Email sent to or from the Principal Financial Group or any of its
member companies may be retained as required by law or regulation.
Nothing in this message is intended to constitute an Electronic signature for
purposes of the Uniform Electronic Transactions Act (UETA) or the Electronic
Signatures in Global and National Commerce Act ("E-Sign") unless a specific
statement to the contrary is included in this message.
If you no longer wish to receive any further solicitation from the Principal
Financial Group you may unsubscribe at
https://www.principal.com/do-not-contact-form any time.
If you are a Canadian resident and no longer wish to receive commercial
electronic messages you may unsubscribe at
https://www.principal.com/do-not-email-request-canadian-residents any time.
This message was secured by Zix(R).
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "Library Server" Access Now "Forbidden"?
Thanks for the update. Just wondering what their DR plan is? For all the 'wild eyed pistol wavers' thanks to Ibm-main for keeping us in the know. In a message dated 9/5/2018 4:07:58 PM Central Standard Time, chale...@us.ibm.com writes: the plan is still to get it back up and running as soon as possible, with "as soon as possible" occurring within the next few weeks or hopefully even few days. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM share-option 4
> Who said SVS did not have VSAM? Steve Thompson > SVS certainly did have VSAM Indeed. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Mark Waterbury <01c3f560aac1-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, September 5, 2018 6:19 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: VSAM share-option 4 Who said SVS did not have VSAM? SVS certainly did have VSAM ... It was an ICR -- Independent Component Release -- so somewhat tricky to get it installed into SVS, but once installed, it did work... and CICS/VS used it ... This was on SVS 1.7 circa 1976-77... And, just like on MVS, on SVS, we were taught that: Share optionsmeans3Close your eyes4 Close your eyes and step on the gas! Does that jog anyone's memory? Mark S. Waterbury On Wednesday, September 5, 2018, 12:35:26 AM EDT, Seymour J Metz wrote: > VSAM was implemented at the OS level with DOS/VS (and IIRC, > DOS/VS was first to have VSAM with MVS|VS1 to follow), where with > OS (OS/VS1 or MVS) What was SVS, chopped liver? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Steve Thompson Sent: Tuesday, September 4, 2018 8:35 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: VSAM share-option 4 Yes your reading and interpretation is essentially correct. VSAM was implemented at the OS level with DOS/VS (and IIRC, DOS/VS was first to have VSAM with MVS|VS1 to follow), where with OS (OS/VS1 or MVS) it was implemented at the address space level. Whoever did your migration, if they did not have a background involving DOS/VS_ and just did a flat migration to MVS (z/OS), you can get royally shafted. The SHARE OPTIONS between the two systems are very different and one has to know and understand this to do a proper migration and Catalog structures are very different between the two systems. Where you would do backups by CATALOG, a CATALOG does not OWN the volumes in an MVS shop. But they did in a DOS/VS shop. And I hate to break this to you at this late date, but if the migrators didn't know it, the z/VSE system was an XA I/O system and so the performance increase for I/O that one expected in days of yore in going to z/OS will not be there (until DOS/VSE/ESA, DOS systems were BASE S/370 using the OLD SIO/SIOF, etc. and not SSCH and related instructions). You may actually lose performance in the z/OS environment as a result. Regards, Steve Thompson On 09/04/2018 07:42 PM, Tony Thigpen wrote: > My main background is z/VSE but now I have to manage a bunch of > z/OS sites, including one that recently converted from z/VSE to > z/OS. > > On z/VSE, share-option 4 means that VSAM will prevent any read or > write integrity exposures when multiple tasks are accessing the > same VSAM file. > > z/VSE VSAM will internally lock any CI that is being updated so > that nobody else can update the CI. This ENQ/DEQ is handled by > the IBM provided VSAM IO routines at the task level. > Additionally, VSAM will flush all update buffers after a write or > update. And, it will not buffer reads when reading a share-option > 4 file. (I am being somewhat general in the descriptions, so the > details are a little more complicated.) All this to make sure > that the records on disk and the records in buffers match. > > Now, with z/OS, my reading of the VSAM Demystified RedBook leads > me to the following: > 1) Share-option 4 allows multiple open for update, but expects > the program, not the VSAM subsystem, to perform the ENQ/DEQs. > 2) If a program does not perform ENQ/DEQs, then data integrity is > lost as multiple tasks can update the same record concurrently. > 3) VSAM/RLS is one way to protect the data, but that is another > can of worms. > > Am I understanding the z/OS side correctly? > -- 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: Auto backup of zfs
Please refer to this Statement of Direction regarding the intent to enhance DFSMShsm and DFSMSdss to backup and recover individual files within a zFS. https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN&subtype=CA&htmlfid=877/ENUSZP18-0290&appname=lenovospain&language=es Glenn Wilcock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Co:Z question
On 6 September 2018 at 09:13, Sankaranarayanan, Vignesh wrote: > On mainframe, a dataset has £ (the pound symbol) in multiple records. > I'm transferring to a RHEL box with lzopts="mode=text". > The £ shows up as a $. > > I ran the COZ job with the following in the first //SFTPIN input: > export COZ_LOG="T,Translator=F" > > I see these relevant lines in the log: > ZosSettingsÝI¨: Transfer options: > clientcp=IBM-1047,mode=text,servercp=ISO8859-1,trim > TranslatorÝF¨: -> Translator(IBM-1047, ISO8859-1, , 0, 0) Vignesh, Your data is probably not encoded in CP 1047, but more likely the UK CECP 285. CP 1047 has the dollar sign at 5B, the pound sterling sign at B1, and the cent sign at 4A. CP 285 has sterling at 5B, dollar at 4A, and cent at B0. But be careful - you are very likely to have a de facto mix of encodings in various data, depending on where it came from. Changing your translation from 1047 to 285 may break something else. (For example, your log lines quoted above show dodgy characters right after ZosSettings and Translator. What characters do you see there when you look at them on z/OS? Are they perhaps square brackets?) Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Co:Z question
[Default] On 6 Sep 2018 06:14:22 -0700, in bit.listserv.ibm-main vignesh.v.sankaranaraya...@marks-and-spencer.com (Sankaranarayanan, Vignesh) wrote: >Hello! > >On mainframe, a dataset has £ (the pound symbol) in multiple records. >I'm transferring to a RHEL box with lzopts="mode=text". >The £ shows up as a $. The locale of the data set should be set to the UK or other pound sterling locale. The dollar sign and the pound sterling sign share the same code point and both share it with the yen sign. Clark Morris > >I ran the COZ job with the following in the first //SFTPIN input: >export COZ_LOG="T,Translator=F" > >I see these relevant lines in the log: >ZosSettingsÝI¨: Transfer options: > clientcp=IBM-1047,mode=text,servercp=ISO8859-1,trim >TranslatorÝF¨: -> Translator(IBM-1047, ISO8859-1, , 0, 0) > >This is the output for 'locale' in the target RHEL machine: >-sh-4.2$ locale >LANG=en_GB.UTF-8 >LC_CTYPE="en_GB.UTF-8" >LC_NUMERIC="en_GB.UTF-8" >LC_TIME="en_GB.UTF-8" >LC_COLLATE="en_GB.UTF-8" >LC_MONETARY="en_GB.UTF-8" >LC_MESSAGES="en_GB.UTF-8" >LC_PAPER="en_GB.UTF-8" >LC_NAME="en_GB.UTF-8" >LC_ADDRESS="en_GB.UTF-8" >LC_TELEPHONE="en_GB.UTF-8" >LC_MEASUREMENT="en_GB.UTF-8" >LC_IDENTIFICATION="en_GB.UTF-8" >LC_ALL= >-sh-4.2$ > > >Can you please help / suggest on how to maintain the £ > > >- Vignesh >Mainframe Infrastructure > > >MARKSANDSPENCER.COM > >Unless otherwise stated above: >Marks and Spencer plc >Registered Office: >Waterside House >35 North Wharf Road >London >W2 1NW > >Registered No. 214436 in England and Wales. > >Telephone (020) 7935 4422 >Facsimile (020) 7487 2670 > >www.marksandspencer.com > >Please note that electronic mail may be monitored. > >This e-mail is confidential. If you received it by mistake, please let us know >and then delete it from your system; you should not copy, disclose, or >distribute its contents to anyone nor act in reliance on this e-mail, as this >is prohibited and may be unlawful. > >-- >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: Co:Z question
One quick thought is that perhaps you are looking at the mainframe data with an emulator that does not use EBCDIC CODEPAGE 1047? You appear to be transferring data from the mainframe and have specified a transformation from EBCDIC CodePage 1047 to ASCII ISO-8859-1. The Pound Sterling sign in EBCDIC CodePage 1047 is x'B1'. If you look at your mainframe data in hex, is this the value you see? In ISO-8859-1, the Pound Sterling sign is x'A3'. Since you are instead seeing a Dollar Sign in ISO-8859-1 (x'24'), then I would expect to see an underlying hex value of x'5B' for the mainframe EBCDIC CodePage 1047 data. Can you use a hex editor on both platforms and share what you see for the hex values of the character in the mainframe as well as on your distributed platform, post-transformation? Maybe then I can help make sense of what is happening. ...Cameron On Thu, Sep 6, 2018 at 9:14 AM Sankaranarayanan, Vignesh < vignesh.v.sankaranaraya...@marks-and-spencer.com> wrote: > Hello! > > On mainframe, a dataset has £ (the pound symbol) in multiple records. > I'm transferring to a RHEL box with lzopts="mode=text". > The £ shows up as a $. > > I ran the COZ job with the following in the first //SFTPIN input: > export COZ_LOG="T,Translator=F" > > I see these relevant lines in the log: > ZosSettingsÝI¨: Transfer options: > clientcp=IBM-1047,mode=text,servercp=ISO8859-1,trim > TranslatorÝF¨: -> Translator(IBM-1047, ISO8859-1, , 0, 0) > > This is the output for 'locale' in the target RHEL machine: > -sh-4.2$ locale > LANG=en_GB.UTF-8 > LC_CTYPE="en_GB.UTF-8" > LC_NUMERIC="en_GB.UTF-8" > LC_TIME="en_GB.UTF-8" > LC_COLLATE="en_GB.UTF-8" > LC_MONETARY="en_GB.UTF-8" > LC_MESSAGES="en_GB.UTF-8" > LC_PAPER="en_GB.UTF-8" > LC_NAME="en_GB.UTF-8" > LC_ADDRESS="en_GB.UTF-8" > LC_TELEPHONE="en_GB.UTF-8" > LC_MEASUREMENT="en_GB.UTF-8" > LC_IDENTIFICATION="en_GB.UTF-8" > LC_ALL= > -sh-4.2$ > > > Can you please help / suggest on how to maintain the £ > > > - Vignesh > Mainframe Infrastructure > > > MARKSANDSPENCER.COM > > Unless otherwise stated above: > Marks and Spencer plc > Registered Office: > Waterside House > 35 North Wharf Road > London > W2 1NW > > Registered No. 214436 in England and Wales. > > Telephone (020) 7935 4422 > Facsimile (020) 7487 2670 > > www.marksandspencer.com > > Please note that electronic mail may be monitored. > > This e-mail is confidential. If you received it by mistake, please let us > know and then delete it from your system; you should not copy, disclose, or > distribute its contents to anyone nor act in reliance on this e-mail, as > this is prohibited and may be unlawful. > > -- > 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: Co:Z question
On 2018-09-06, at 07:13:54, Sankaranarayanan, Vignesh wrote: > > On mainframe, a dataset has £ (the pound symbol) in multiple records. > I'm transferring to a RHEL box with lzopts="mode=text". > The £ shows up as a $. > > I ran the COZ job with the following in the first //SFTPIN input: > export COZ_LOG="T,Translator=F" > > I see these relevant lines in the log: >ZosSettingsÝI¨: Transfer options: > clientcp=IBM-1047,mode=text,servercp=ISO8859-1,trim >TranslatorÝF¨: -> Translator(IBM-1047, ISO8859-1, , 0, 0) > > This is the output for 'locale' in the target RHEL machine: > -sh-4.2$ locale > LANG=en_GB.UTF-8 > LC_CTYPE="en_GB.UTF-8" > My first guess would be to use UTF-8 ratner than ISO8859-1 in the Translator(), since that's what Locale tells you. How does Co:Z deal with MBDATACONN? Why do I see incorrectly rendered characters in "ZosSettingsÝI¨:"? I hate EBCDIC! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Co:Z question
I tried sticking in 'servercp' like below.. lzopts="mode=text,servercp=UTF-8" but no luck Got this msg in the log.. is this normal? CUNLCNV not SBCS->SBCS, discarding translateTable - Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sankaranarayanan, Vignesh Sent: 06 September 2018 14:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Co:Z question Hello! On mainframe, a dataset has £ (the pound symbol) in multiple records. I'm transferring to a RHEL box with lzopts="mode=text". The £ shows up as a $. I ran the COZ job with the following in the first //SFTPIN input: export COZ_LOG="T,Translator=F" I see these relevant lines in the log: ZosSettingsÝI¨: Transfer options: clientcp=IBM-1047,mode=text,servercp=ISO8859-1,trim TranslatorÝF¨: -> Translator(IBM-1047, ISO8859-1, , 0, 0) This is the output for 'locale' in the target RHEL machine: -sh-4.2$ locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_PAPER="en_GB.UTF-8" LC_NAME="en_GB.UTF-8" LC_ADDRESS="en_GB.UTF-8" LC_TELEPHONE="en_GB.UTF-8" LC_MEASUREMENT="en_GB.UTF-8" LC_IDENTIFICATION="en_GB.UTF-8" LC_ALL= -sh-4.2$ Can you please help / suggest on how to maintain the £ - Vignesh Mainframe Infrastructure MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. -- 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
Co:Z question
Hello! On mainframe, a dataset has £ (the pound symbol) in multiple records. I'm transferring to a RHEL box with lzopts="mode=text". The £ shows up as a $. I ran the COZ job with the following in the first //SFTPIN input: export COZ_LOG="T,Translator=F" I see these relevant lines in the log: ZosSettingsÝI¨: Transfer options: clientcp=IBM-1047,mode=text,servercp=ISO8859-1,trim TranslatorÝF¨: -> Translator(IBM-1047, ISO8859-1, , 0, 0) This is the output for 'locale' in the target RHEL machine: -sh-4.2$ locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_PAPER="en_GB.UTF-8" LC_NAME="en_GB.UTF-8" LC_ADDRESS="en_GB.UTF-8" LC_TELEPHONE="en_GB.UTF-8" LC_MEASUREMENT="en_GB.UTF-8" LC_IDENTIFICATION="en_GB.UTF-8" LC_ALL= -sh-4.2$ Can you please help / suggest on how to maintain the £ - Vignesh Mainframe Infrastructure MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: load library lrecl=??
LRECL has no meaning for RECFM=U as far as the system goes. It is recorded in the DSCB, but that is all. Anyway, only QSAM ever uses LRECL for any dataset. So there's no good reason for specifying LRECL on a load library. It can default to 0 just fine, because it's meaningless. As far as directory reading goes, the DCB would need to specify DSORG, RECFM, BLKSIZE overrides, and KEYLEN with BSAM; again LRECL is irrelevant. For QSAM it would be needed, but letting it default to the DSCB would be fatuous. sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E's CIDTABL useful/needed?
On 9/6/2018 8:19 AM, Richards, Robert B. wrote: I have created my new REXX code "prepending" the SSA connector to all SMP/E GIM datasets LIBDEFs, etc.. While looking at the original clist code, I came across the allocation of the CIDTABL DD pointing to the SMPTLIB dataset. A quick search on Google trying to find out if the CIDTABL DD was still useful/needed yielded no useable results. Anyone know if it is needed/useful? Kurt Q? :) CIDTABL is an oldie, and is unused. It was for the CBIPO Installation Dialogs which went away when ServerPac arrived, back in z/OS V1.1 (March 2001?). You don't need the CIDTABL DD. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E's CIDTABL useful/needed?
Thanks Kurt! I suspected as much. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kurt Quackenbush Sent: Thursday, September 06, 2018 8:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E's CIDTABL useful/needed? On 9/6/2018 8:19 AM, Richards, Robert B. wrote: > I have created my new REXX code "prepending" the SSA connector to all > SMP/E GIM datasets LIBDEFs, etc.. While looking at the original clist > code, I came across the allocation of the CIDTABL DD pointing to the > SMPTLIB dataset. A quick search on Google trying to find out if the > CIDTABL DD was still useful/needed yielded no useable results. > > Anyone know if it is needed/useful? Kurt Q? :) CIDTABL is an oldie, and is unused. It was for the CBIPO Installation Dialogs which went away when ServerPac arrived, back in z/OS V1.1 (March 2001?). You don't need the CIDTABL DD. Kurt Quackenbush -- IBM, SMP/E Development -- 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
SMP/E's CIDTABL useful/needed?
Kind souls, I am revisiting our clist code that invokes our SMP/E dialog. On a whim, I am converting it to REXX for the new z/OS 2.3 ServerPac that we are in the process of implementing. I was curious about what was in the new SMP/E CSI(s) *before* that system is IPLable. I have created my new REXX code "prepending" the SSA connector to all SMP/E GIM datasets LIBDEFs, etc.. While looking at the original clist code, I came across the allocation of the CIDTABL DD pointing to the SMPTLIB dataset. A quick search on Google trying to find out if the CIDTABL DD was still useful/needed yielded no useable results. Anyone know if it is needed/useful? Kurt Q? :) Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ASCRE and ACEE inheritance
Has anyone had any luck starting a new address-space with ASCRE but specifying a non-default ACEE? I tried our usual technique of inserting the desired ACEE address into TCBSENV and ASXBSENV but it was ignored. The obvious solution would be to set the ACEE in the address-space initialisation exit and that is what I did and it seemed to work. The new STC is still owned by the mother task's ACEE but data set accesses are governed by the new ACEE. The trouble began when I tried this on a system with TEMPDSN turned on in RACF. The temporary data sets seem to be owned by the original ACEE so the mainline code cannot access them. We solved this by doing dynamic allocation of the temporary data sets but there must be a better way! How can I specify the ACEE I want when I do the ASCRE? Thanks Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
