Re: Conversion from Unisys Cobol file definitions to zOS
At 00:20 -0600 on 01/15/2016, Paul Gilmartin wrote about Re: Conversion from Unisys Cobol file definitions to zOS: On Fri, 15 Jan 2016 00:28:41 -0500, Robert A. Rosenberg wrote: > ... did not support 8-Track tapes. ... Weren't those mostly used in automobiles? I remember when a colleague first saw a 3480 cartridge he asked, "Is that an 8-track?" OOPS. I meant to type 8-bit tapes not 8-track tapes. -- 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: Conversion from Unisys Cobol file definitions to zOS
At 01:02 -0500 on 01/15/2016, Ed Finnell wrote about Re: Conversion from Unisys Cobol file definitions to zOS: It's been years but I got involved in Notis(library) imports that were Ascii 8trks. The first cut was OTPCD=Q, but it was a 'strict ASCII' that didn't convert diacriticals. Think they ended up using SAS but it's been a very long time. That would be a given if OPTCD=Q was based on a 7-bit ASCII (ie: US-ASCII in Email Terms). To get diacriticals you need 8-bit ASCII (ie: ISO-8859-1/etc). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conversion from Unisys Cobol file definitions to zOS
VHS or Beta Max. 9trks for 3420's. In a message dated 1/15/2016 12:20:59 A.M. Central Standard Time, 000433f07816-dmarc-requ...@listserv.ua.edu writes: Weren't those mostly used in automobiles? I remember when a colleague first saw a 3480 cartridge he asked, "Is that an 8-track?" -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conversion from Unisys Cobol file definitions to zOS
On Fri, 15 Jan 2016 00:28:41 -0500, Robert A. Rosenberg wrote: > >... did not support 8-Track tapes. ... > Weren't those mostly used in automobiles? I remember when a colleague first saw a 3480 cartridge he asked, "Is that an 8-track?" -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conversion from Unisys Cobol file definitions to zOS
It's been years but I got involved in Notis(library) imports that were Ascii 8trks. The first cut was OTPCD=Q, but it was a 'strict ASCII' that didn't convert diacriticals. Think they ended up using SAS but it's been a very long time. In a message dated 1/14/2016 11:29:26 P.M. Central Standard Time, hal9...@panix.com writes: used ONLY on 7-track tapes. This might be that the non-IBM machines writing ASCII only wrote 7-Track Tapes and did not support 8-Track tapes. This was years ago when I needed to support it and things probably have changed since then. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conversion from Unisys Cobol file definitions to zOS
At 09:26 -0600 on 01/13/2016, Paul Gilmartin wrote about Re: Conversion from Unisys Cobol file definitions to zOS: Does OPTCD=Q work on all device types? I had got the impression it applied only to tapes. My impression may be wrong but I seem to remember that OPTCD=Q was used ONLY on 7-track tapes. This might be that the non-IBM machines writing ASCII only wrote 7-Track Tapes and did not support 8-Track tapes. This was years ago when I needed to support it and things probably have changed since then. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conversion from Unisys Cobol file definitions to zOS
Curtis Pew wrote: >Bottom line, I think it’s pretty clearly documented that BSAM/QSAM >supports character set conversion, but only when tape is involved. Or virtual tape. Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OPTCD=Q (was Conversion from Unisys Cobol file definitions to zOS)
Hi In a recent post it was stated "Bottom line, I think it's pretty clearly documented that BSAM/QSAM supports character set conversion, but only when tape is involved. I agree that that's a pretty ridiculous restriction" and this was for both OPRCD=Q and CCSID. This may seem like a ridiculous restriction but I see no incentive or requirement to change it. OPTCD=Q in particular harks back to when most installations transferred data via tape, not even cartridge in those days. Here in the UK all the main banks used IBM equipment but the central clearing centre for Standing Orders and Direct Debits used an indigenous system and hence OPTCD=Q was used a lot. These days most organisations rely on network transfers and have bespoke products such as Connect Direct to handle the traffic. These products are more than capable of handling character conversion as a minimum. Looking back at the original post it seem that the issue was more sophisticated than simple character conversion and related to field alignment and sizes, i.e. converting a 3-digit field with a length of one and half bytes into a two byte field. Kind Regards - Terry Director KMS-IT Limited 228 Abbeydale Road South Dore Sheffield S17 3LA UK Reg : 3767263 Outgoing e-mails have been scanned, but it is the recipients responsibility to ensure their anti-virus software is up to date. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conversion from Unisys Cobol file definitions to zOS
> On Jan 13, 2016, at 10:56 PM, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > But does mere mention of OPTCD=Q mean its use is restricted to tapes? > Might not it apply to other device types? (It's hard to prove a negative) > But if it's so restricted it's another instance of IBM's implementing a > useful facility at the wrong layer. ASCII<->EBCDIC conversion is surely > useful on other device types. The JCL Reference manual says for OPTCD=Q: indicates that all the user data in the data set is in ASCII. BSAM or QSAM converts the records from ASCII to EBCDIC when reading and converts the records from EBCDIC to ASCII when writing. The data set must reside on magnetic tape and must not contain IBM standard labels. The record format (RECFM) must not be V but can be D. If the label type is ISO/ANSI/FIPS, specified as LABEL=(,AL), the system forces OPTCD=Q. > > Is this software in the OS or microcode in the control unit? I’m pretty sure it’s in the BSAM/QSAM access method routines. > > And what about CCSID. According to the documentation, this: In the JCL manual under CCSID, it says: Data conversion is supported on access to ISO/ANSI Version 4 tapes using access methods BSAM or QSAM, but not using EXCP. Bottom line, I think it’s pretty clearly documented that BSAM/QSAM supports character set conversion, but only when tape is involved. I agree that that’s a pretty ridiculous restriction. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conversion from Unisys Cobol file definitions to zOS
On Wed, 13 Jan 2016 22:30:19 -0500, David S. wrote: >Paul Gilmartin wrote: > >> Does OPTCD=Q work on all device types? >> I had got the impression it applied only to tapes. > >Yes, tape is implicit. OPTCD=Q only works with tape. >ASCII conversion topic in "z/OS DFSMS: Using Magnetic Tapes": >http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dgt2m320/3.7.1 > But does mere mention of OPTCD=Q mean its use is restricted to tapes? Might not it apply to other device types? (It's hard to prove a negative) But if it's so restricted it's another instance of IBM's implementing a useful facility at the wrong layer. ASCII<->EBCDIC conversion is surely useful on other device types. Is this software in the OS or microcode in the control unit? And what about CCSID. According to the documentation, this: //STEP3 EXEC PGM=IEBGENER,CCSID=1047 //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY //SYSUT2DD PATHMODE=(SIRUSR,SIWUSR), // PATHOPTS=(OCREAT,OTRUNC,OWRONLY), // CCSID=1209, // PATH='&OBFUSC/work/tmp/UTF-8' //SYSUT1DD * This is a UNIX UTF-8 test. cent: "¢" //* ... should write SYSUT2 in UTF-8, yet it seems to write EBCDIC. Or am I overlooking yet another restriction? But at the very least, if it's supposed to not work it should fail with an error message. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conversion from Unisys Cobol file definitions to zOS
Paul Gilmartin wrote: > Does OPTCD=Q work on all device types? > I had got the impression it applied only to tapes. Yes, tape is implicit. OPTCD=Q only works with tape. ASCII conversion topic in "z/OS DFSMS: Using Magnetic Tapes": http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dgt2m320/3.7.1 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conversion from Unisys Cobol file definitions to zOS
On Wed, 13 Jan 2016 08:51:47 -0500, David S. wrote: >... >If the data is *all* in character format, then conversion from ASCII to >EBCDIC is easy using OPTCD=Q on the DCB. > Does OPTCD=Q work on all device types? I had got the impression it applied only to tapes. There's also lately a CCSID option on both the EXEC statement and the DD statement which seems to be intended to convert between any CCSID used by the program and another CCSID appearing in a file. IIRC, I tried it and didn't get expected results. Perhaps I overreached with something such as: //SETPEXEC PGM=IEBGENER,CCSID=1047 //SYSUT2 DD CCSID=1209,PATH='...',.. (UTF-8) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conversion from Unisys Cobol file definitions to zOS
"... conversion utility or compiler directive to make the translation from the Unisys implementation of Cobol FD's to Enterprise Cobol?" If the data is *all* in character format, then conversion from ASCII to EBCDIC is easy using OPTCD=Q on the DCB. Unfortunately, that's seldom the case, which makes things *much* more complicated. You mention the half-byte alignment problem, so you're already aware of that one. There's also the issue of how signed and unsigned decimal fields are handled (Unisys=leftmost position or none, IBM=rightmost position always). MCP was inherited from the Burroughs side of the Unisys family, so there will likely be some detailed information on the proprietary data types somewhere here: http://bitsavers.trailing-edge.com/pdf/burroughs Wish I could be more specific, but my depth of expertise is more on the IBM side. If anyone can point to a *specific* reference for Burroughs/Unisys data types, please post it here. I'd love to see it! There was a recent discussion of specific Unisys to IBM conversion issues on the "Mainframe Assembler Professionals" LinkedIn group, here: http://www.linkedin.com/groups/1462937/1462937-6049636244294488065 BFX was mentioned (a Netex product), was mentioned as a solution, and the person posting sounded very positive about it, but looking at their documentation, I don't see a reference which specifically says it does Unisys to IBM conversion - z/OS to Unisys, yes, but not the other way around: http://www.netexsw.com/nesi/support/ReleasedDocs/H21x/man-ref-H211-08.pdf And if it is supported, it looks like you basically write the conversion code yourself, in Assembler, around which BFX is basically just a "wrapper". For a fee, there are some companies which can do the conversion for you, such as: http://www.discinterchange.com > Date:Tue, 12 Jan 2016 16:04:58 + > From: "Ambros, Thomas" > Subject: Conversion from Unisys Cobol file definitions to zOS > > My apologies if there is a Cobol listserv that I should have subscribed to > and submitted the question there, if someone knows of it please let me know > so I can redirect to the correct place. > > Pardon me, also, if I use terms incorrectly in phrasing my question > because I couldn't be weaker in application programming or Cobol > idiosyncracies. > > Our site has occasion to import files from a Unisys site running 'MCP > Level 57 Miser level 15.2', and integrate the data with the application > datasets on the local system. I do not know the Cobol product the Unisys > site is using, I have inquiries out but no answers yet. There are at least > a few items causing our application programmers some difficulties. > > For example, it appears that the COMP fields in the Unisys file do not > occupy storage the same as they do on zOS. For example, a COMP field with > three digits occupies one and one-half bytes on the Unisys file whereas on > zOS it would be a halfword. > > Given the size and number of the files and descriptions to convert, coding > a conversion by hand is not entirely practical. > > I realize this is a pretty vague request, but does anyone know of a > conversion utility or compiler directive to make the translation from the > Unisys implementation of Cobol FD's to Enterprise Cobol? I have done some > basic Google searching but nothing I find appears to address this sort of > thing very closely. > > Thomas Ambros > zEnterprise Operating Systems > zEnterprise Systems Management > 518-436-6433 > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conversion from Unisys Cobol file definitions to zOS
Tom, Contact me offline on this via email. I am in the process of doing the same thing for a client on the east coast. Regards, Mitch McCluhan mitc...@aol.com -Original Message- From: Ambros, Thomas To: IBM-MAIN Sent: Tue, Jan 12, 2016 10:05 am Subject: Conversion from Unisys Cobol file definitions to zOS My apologies if there is a Cobol listserv that I should have subscribed to and submitted the question there, if someone knows of it please let me know so I can redirect to the correct place. Pardon me, also, if I use terms incorrectly in phrasing my question because I couldn't be weaker in application programming or Cobol idiosyncracies. Our site has occasion to import files from a Unisys site running 'MCP Level 57 Miser level 15.2', and integrate the data with the application datasets on the local system. I do not know the Cobol product the Unisys site is using, I have inquiries out but no answers yet. There are at least a few items causing our application programmers some difficulties. For example, it appears that the COMP fields in the Unisys file do not occupy storage the same as they do on zOS. For example, a COMP field with three digits occupies one and one-half bytes on the Unisys file whereas on zOS it would be a halfword. Given the size and number of the files and descriptions to convert, coding a conversion by hand is not entirely practical. I realize this is a pretty vague request, but does anyone know of a conversion utility or compiler directive to make the translation from the Unisys implementation of Cobol FD's to Enterprise Cobol? I have done some basic Google searching but nothing I find appears to address this sort of thing very closely. Thomas Ambros zEnterprise Operating Systems zEnterprise Systems Management 518-436-6433 This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in the SUBJECT line. -- 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
Conversion from Unisys Cobol file definitions to zOS
My apologies if there is a Cobol listserv that I should have subscribed to and submitted the question there, if someone knows of it please let me know so I can redirect to the correct place. Pardon me, also, if I use terms incorrectly in phrasing my question because I couldn't be weaker in application programming or Cobol idiosyncracies. Our site has occasion to import files from a Unisys site running 'MCP Level 57 Miser level 15.2', and integrate the data with the application datasets on the local system. I do not know the Cobol product the Unisys site is using, I have inquiries out but no answers yet. There are at least a few items causing our application programmers some difficulties. For example, it appears that the COMP fields in the Unisys file do not occupy storage the same as they do on zOS. For example, a COMP field with three digits occupies one and one-half bytes on the Unisys file whereas on zOS it would be a halfword. Given the size and number of the files and descriptions to convert, coding a conversion by hand is not entirely practical. I realize this is a pretty vague request, but does anyone know of a conversion utility or compiler directive to make the translation from the Unisys implementation of Cobol FD's to Enterprise Cobol? I have done some basic Google searching but nothing I find appears to address this sort of thing very closely. Thomas Ambros zEnterprise Operating Systems zEnterprise Systems Management 518-436-6433 This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in the SUBJECT line. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
