Visara CNA8000 question

Hi, we have a possible need to connect a token-ring link to a z13 (don't ask) and were considering one option, but now another has appeared. We're wondering if anyone else is using a Visara CNA8000 for this? It seems a simpler option than the other one as it takes a token-ring link on one

Re: Curious about IBM time conversion example program

On 21/07/2017 6:43 AM, Paul Gilmartin wrote: On Thu, 20 Jul 2017 14:33:58 -0700, Charles Mills wrote: Yes, negative UNIX times are legal and generally work. I had understood that negative time_t values are illegal but generally work. The closest I can find in POSIX is:

Re: Curious about IBM time conversion example program

On 21/07/2017 1:11 AM, Kirk Wolf wrote: As usual, the knowledge and helpfulness of those on this list is astonishing. I'm actually writing this in Java (to 64-bit java "long" epoch seconds, from both STCK and STCKE inputs), but the sample IBM assembler code initially puzzled me. I had to do

Re: Curious about IBM time conversion example program

On 20 July 2017 at 22:13, Bill Godfrey wrote: > There are 17 leap days from 1900 to 1970, not 16. Just write them out > starting at 1904, 1908... and count them. > > That would make the results one day later than they should be. > Dang... Obi-Wan error. I just tried it on

Re: Curious about IBM time conversion example program

On Thu, 20 Jul 2017 16:58:11 -0700, Charles Mills wrote: >Far be it from me to try to interpret the POSIX standards. It's definitely >signed on z/OS. > >typedef long time_t; > >Why waste a bit if you are not going to support negative? Making it unsigned >would have put off the Year 2038

Backing up EMC DLM

Is anyone using a Quantum (quantum.com) device to back up data from an EMC DLM? (Disk Library for Mainframe - looks like tape to the mainframe) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Re: Curious about IBM time conversion example program

There are 17 leap days from 1900 to 1970, not 16. Just write them out starting at 1904, 1908... and count them. That would make the results one day later than they should be. The microseconds value should be 22089888, which in hex is 7d91048bca000, and after shifting that 12 bits to

Re: Curious about IBM time conversion example program

Far be it from me to try to interpret the POSIX standards. It's definitely signed on z/OS. typedef long time_t; Why waste a bit if you are not going to support negative? Making it unsigned would have put off the Year 2038 problem an additional 68+ years. I guess my assertion of negative

Re: Curious about IBM time conversion example program

On Thu, 20 Jul 2017 14:33:58 -0700, Charles Mills wrote: >Yes, negative UNIX times are legal and generally work. > I had understood that negative time_t values are illegal but generally work. The closest I can find in POSIX is:

Re: Enterprise COBOL V6.2

I'm still not sure exactly what you are saying, but I will say this. Prior to Enterprise COBOL V6 an item within the linkage section that had a VALUE clause would generate a warning. I believe this is what you stated. But now it's not even a warning. It's certainly not an error, which is

Re: Curious about IBM time conversion example program

Yes, negative UNIX times are legal and generally work. But a shift -- arithmetic, not logical! -- of a negative number works, except it sometimes ends up off by one, which is not going to be a huge problem here, right? One microsecond. shifted right one is , but in true

Re: Enterprise COBOL V6.2

I'm not clear on what you are saying here. Can you give an example of both the code and the error message? From: IBM Mainframe Discussion List on behalf of Cameron Conacher Sent: Thursday, July 20, 2017 2:43 PM

Re: Curious about IBM time conversion example program

Good point. A Unix EPOC time value is a signed integer, relative to midnight Jan 1, 1970. So STCK values between 1900 and 1970 would be negative after subtracting the 1900-1970 offset value, and a SRDL instruction would not be appropriate. Kirk Wolf Dovetailed Technologies http://dovetail.com

Re: Curious about IBM time conversion example program

Right Charles. SECS_PER_TOD_UNIT is an bad (inverted) name. Kirk Wolf Dovetailed Technologies http://dovetail.com On Thu, Jul 20, 2017 at 3:53 PM, Kirk Wolf wrote: > X'7A12' is 1 million * 4096 / 2. > > There are 0x1000 TOD units in a microsecond; 1 million * 0x1000 in

Re: Curious about IBM time conversion example program

Not following all this too closely, but if UNIX is a signed value, can it go prior to 1900 and that is why they did math rather than shifting? Just a question. Chris Blaicher Technical Architect Mainframe Development P: 201-930-8234 | M: 512-627-3803 E: cblaic...@syncsort.com Syncsort

Re: Curious about IBM time conversion example program

X'7A12' is 1 million * 4096 / 2. There are 0x1000 TOD units in a microsecond; 1 million * 0x1000 in a second. So if you use 64 bit arithmetic, there is nothing wrong with: stck -= TOD_EPOC_OFFSET; // 1900 to 1970 offset: 0x7D91048BCA00L long epoc_secs = stck / SECS_PER_TOD_UNIT;//

Re: Enterprise COBOL V6.2

Hello everyone. COBOL 6.1 introduced a "feature" where VALUE clauses that are used for initialization are flagged as errors. Ever since I began using COBL in the seventies, this would be treated as a warning. Personally, I consider it bad form, but the compiler happily marched on. We have a number

Re: Curious about IBM time conversion example program

X'7A12' is (4096 * 100) / 2. The comment is backwards or inverted: should say TOD units per second (divided by 2). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Thursday, July 20, 2017 1:10 PM

Re: retrieve OPDATA from a program?

SHOWMVS, CBT tape file 492 has the logic you want. I don't think it's a programmable interface though: L R4,CVTCUCB Unit Control Module (UCM) USING UCM,R4 L R5,UCMBFEXT UCM fixed extension USING UCMFEXTA,R5

RES: Enterprise COBOL V6.2

Hello all, Is XTIOT supported by Cobol 6.2 ? Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto BANCO BRADESCO S.A. 4250 / DITI Engenharia de Software Sistemas Operacionais Mainframes Tel: +55 11 3684-9602 R: 49602 3-1404 Fax: +55 11 3684-4427 -Mensagem original- De: IBM

Re: Curious about IBM time conversion example program

On 20 July 2017 at 13:11, Kirk Wolf wrote: > I'm actually writing this in Java (to 64-bit java "long" epoch seconds, > from both STCK and STCKE inputs), but the sample IBM assembler code > initially puzzled me. I must admit I remain confused by both the sample code and its

retrieve OPDATA from a program?

Any idea how to get subsystem command prefixes prom a program, without using /d optdata? I looked at the related macros, but haven't seen anything. ITschak -- ITschak Mugzach *|** IronSphere Platform* *|** Automatic ISCM** (Information Security Contiguous Monitoring) **| *

Graph HCD Reports

Other than HCM - is there any tool that will take an HCD report and create a graph of the connections (perhaps in excel or visio)? Thanks -- Lionel B. Dyck Mainframe Systems Programmer - TRA

Re: What to do with PTF dogies?

This 'problem' may actually be phantom. I was alarmed when I saw that we have 1500 (!) sysmods in NOAPPLY status. I dug into the report yesterday and discovered that virtually the entire OMEGAMON suite was received at some point but never installed, so all relevant FMIDs plus many hundreds of

Re: Curious about IBM time conversion example program

As usual, the knowledge and helpfulness of those on this list is astonishing. I'm actually writing this in Java (to 64-bit java "long" epoch seconds, from both STCK and STCKE inputs), but the sample IBM assembler code initially puzzled me. Kirk Wolf Dovetailed Technologies http://dovetail.com

Re: What to do with PTF dogies?

Since I wound up in a meeting with someone on the CST team, I verified that everything is supposed to eventually be marked RSU, even PTFs for products that are not part of CST, based on age. There are windowing factors make the delay between COR-close and RSU vary, but generally we would

Re: What to do with PTF dogies?

Can you give us an example of such dogies? Can it be that you received it before it was part of an RSU and you haven't received the latest ++ASSIGN for it? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent:

Re: What to do with PTF dogies?

I have reviewed our current list of unapplied PTFs from LIST NOAPPLY(). The real (unexplained) dogies are way fewer than I expected, fewer than I've seen in the past. Maybe this has become a non-problem. I do want to make a point that some folks may have missed. From the get-go, RSU was not

Re: What to do with PTF dogies?

On Thu, 20 Jul 2017 09:57:31 -0400, Tom Conley wrote: >I'd ask the question "How come these PTF's aren't in an RSU?" Shouldn't >they have gone through CST at some point? I would think so too, unless they have been SUP'ed. -- Tom Marchant

Re: How to see if a dataset is defined with CONTIG ?

Hi, Thank You for the answers, the VTOC is able to provide the answer as indicated. I used a LISTVTOC with the FORMAT option, it shows the CONTIG under the ALLOC column, sample for the record if anyone ever search for this: First dataset defined with SPACE=(CYL,(10,0)):

Re: What to do with PTF dogies?

On 7/19/2017 5:17 PM, Jesse 1 Robinson wrote: It's SOP here to install PTFs by RSU id. SMPE LIST NOAPPLY shows a fair number of PTFs that have languished for quite some because they have never been assigned to RSU. They usually have a PUT id, but we don't ever specify PUTyymm. What do other

Re: How to see if a dataset is defined with CONTIG ?

We have a tool that maps the F1DSCB and it shows: Allocation parms .. C800 11.. Cylinder request ..0. Mass Storage Volume

Re: What to do with PTF dogies?

I have used RSU for years on z/OS and have done many golives with very few software issues. RSU folds in older PTFs that were not previously included and it also looks forward for hipers etc. It is saving customers a lot of research. You can read about it here:

Re: How to see if a dataset is defined with CONTIG ?

You can run a LISTVTOC and look for the DS1CONTG field in the F1 or F8 DSCB for the data set. (Sorry, not sure what authorizations are needed for that but I'd hope we document it.) -- John Eells IBM Poughkeepsie ee...@us.ibm.com

Re: How to see if a dataset is defined with CONTIG ?

I do not believe this information is retained after allocation. However, One clue would be the presence of a secondary allocation. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dirceu Bimonti Ivo Sent: Thursday, July 20, 2017 8:14

Re: How to see if a dataset is defined with CONTIG ?

On Thu, 20 Jul 2017 08:14:28 -0500, Dirceu Bimonti Ivo wrote: > >I am going through a vast list of datasets that were supposed to be defined as >CONTIG, Information from ISPF 3.4 does not show if CONTIG was resquested when >the dataset was created. Our storage product seems to be able to find

How to see if a dataset is defined with CONTIG ?

Hi, I am going through a vast list of datasets that were supposed to be defined as CONTIG, Information from ISPF 3.4 does not show if CONTIG was resquested when the dataset was created. Our storage product seems to be able to find this information when I copy something larger than the dataset

Re: Enterprise COBOL V6.2

Don't need a compiler for that! On Jul 20, 2017, 8:33 AM -0400, Tim Deller , wrote: > "Conditional complication"? > Sounds about right... > > -- > For IBM-MAIN subscribe / signoff / archive access

Re: Enterprise COBOL V6.2

"Conditional complication"? Sounds about right... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What to do with PTF dogies?

Apply by PUT, not RSU. That was you don't get into the problem in the first place. RSU cannot test everything. It is merely a large subset of the more common environments. HTH, -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of

Re: Suppluing software to run on unsupported OS was Re: LE strikes again

Some people haven't bought a z800 or higher. On Wed, Jul 19, 2017 at 10:23 PM, Charles Mills wrote: > ARCH(4) is 390 mode! > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Steve Beaver > Sent: