Client - Server environment using TLS 1.2

We have a TCP/IP z/OS client using "USS ASSEMBLER Callable Services" communicating with a java server (running on any environment). We have a requirement to use TLS 1.2 for this communications. Can someone give me a clue as to where to look on how to do this upgrade?

Re: C++ default parameter question

Compiles just fine extern "OS" { int asmprog( int n, int y = 1 ); } int main( int argc, char *argv[] ) { asmprog(1); return 0; } On 27/05/2016 6:05 AM, Charles Mills wrote: I'm pretty sure I know the answer to this question but wondered if someone knew for sure. If I declare a

Re: C++ default parameter question

Thinking about this once again: I could imagine that one of the different FOO functions could indeed be implemented in ASSEMBLER (without name mangling), if the others stay C++ functions, and then the default mechanism could work for this function, too. But only one of them, otherwise there

Re: C++ default parameter question

Isn't it a problem that with true C++ functions it is possible that functions can exist with the same name but different parameters, for example void FOO (int x); void FOO (double x); void FOO (char *x); and C++ chooses the right one depending on the parameter used on the function call?

Re: C++ default parameter question

Thanks. I was pretty sure that was the case. I just wanted to make sure I was not missing something. It is documented as "C++ only." But it's really "the caller only has to be C++." I guess the called function could be C; you would just have to have a different header declaration -- not unheard

Re: Questions on DPMOD

Thanks. I said "jobstep task" -- I was thinking of a batch job. Right, the ATTACH(X) doc is fairly clear on the relationship of subtasks to the mother task. So this is inherent in the guts of MVS -- not something in PROGxx or somewhere like that? Charles -Original Message- From: IBM

Re: C++ default parameter question

Charles Mills wrote: The reason I am asking ... suppose FOO is a function implemented in assembler, not in C++. The declaration of the default parameter and the invocation with the parameter omitted will still work, right? Apparently so. Of course, fairly easy to test!

Re: Questions on DPMOD

On 5/26/2016 2:51 PM, Charles Mills wrote: 1. Where is the original dispatching and limit priority for the jobstep task set? How do I determine (not with an API at runtime, but in advance with a command or looking at a parm member) what it is presumably going to be? Sigh... the initial

C++ default parameter question

I'm pretty sure I know the answer to this question but wondered if someone knew for sure. If I declare a function void FOO(int x = 1); and call it with FOO() then the construction and passing of an integer parameter with a value of 1 is entirely handled by the calling module, correct? The

Re: CREATED date for migrated data sets?

According to my DFSMShsm Data Areas manual, the Migration Control Data Set Data Set Record has the creation data at offset x'4c' in field MCDDLC. There does not appear to be an HSM utility to extract these records in bulk. You could write a little selection program to read them or use a

Questions on DPMOD

This seems like a pretty basic question but in all my years of coding I have never messed with dispatching priority that I recall. I have read the doc for ATTACH(X) DPMOD and LPMOD. I have read the relevant sections in Chapter 3 of the Assembler Services Guide. Questions: 1. Where is the

Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.

On 5/26/2016 10:29 AM, Jerry Callen wrote: Here are the results: Relative performance: total CPU ECB 1.0 Pause/Resume 4.30 Transfer and Pause3.25 Transfer with separate Pause 4.55 Relative performance: elapsed ECB

Re: CREATED date for migrated data sets?

On Thu, 26 May 2016 13:17:06 -0700, Lizette Koehler wrote: >Probably HLIST is the best. Unless you have Vantage with HSM Option or Tivoli >Storage Suite > >HLIST SELECT(AGE(x,y)) MCDS ODS('your.data.set.output') > >As far as I know, there is no DATE qualification

Re: Product name by module

I checked listserv.ua.edu and this is your first post here. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Product name by module

P-Tracker from UBSHainer is a product that identifies all programs used in either online or batch mainframe asset discovery as it is sometimes called. P-Tracker also identifies call sequences which is helpful for applications folks to determine which modules from where are being used.

AW: CREATED date for migrated data sets?

> Alas, ISPF DSLIST does not show created date for migrated data sets. Those dates are in the data set's DSCB. There is none for migrated ones. So for once, ISPF is not guilty. -- Peter Hunkeler -- For IBM-MAIN subscribe

Re: CREATED date for migrated data sets?

Probably HLIST is the best. Unless you have Vantage with HSM Option or Tivoli Storage Suite HLIST SELECT(AGE(x,y)) MCDS ODS('your.data.set.output') As far as I know, there is no DATE qualification on HLIST. AGE(mindays maxdays) is an optional subparameter of SELECT that specifies a list

Re: CREATED date for migrated data sets?

I think its worse than that. Change 34.115 Variable DCDTIMEC, Data Set Create Time in DCOLDSET is VMACDCOL only populated if May 11, 2016 - the dataset is on an EAV volume (more than 65K CYL) - the volume is the first volume for the dataset (DCDTIMEC

CREATED date for migrated data sets?

I would like to HRECALL all data sets matching a certain pattern and created since 2016-04-01. Alas, ISPF DSLIST does not show created date for migrated data sets. I suppose that if they were created after April 1, they could not have been migrated earlier, so I could use a HLIST. Is there a

Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.

Greg Dyck wrote: > No one every said that Pause/Release was faster or consumed the same > amount of CPU as WAIT/POST, or that they should be used as a universal > replacement for WAIT/POST. They should be used where they provide value. The reason I wrote the test is that the documentation is

Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.

On 5/26/2016 10:29 AM, Jerry Callen wrote: I wrote a simple test program to compare the performance of WAIT/POST and pause elements. The program has two tasks and simply ping-pongs back and forth between them (no overlapped execution). Each task has a synchronization gadget, either an ECB or a

Re: Video that might give you a chuckle

On 16May26:1154+, van der Grijn, Bart (B) wrote: > It's an interesting observation as I always chuckle > when my American coworkers say parmlibe, Here lib does not rhyme with glib, but with tribe and is understood to be short for library. How do you pronouce the full word? -- May the LORD

Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.

He said z13 & ‎z/OS2.2. Sent from my BlackBerry 10 smartphone on the Bell network.   Original Message   From: michelbutz Sent: Thursday, May 26, 2016 13:35 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is

Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.

Can you tell us the following What type of processor The work load What version of z/OS these are relevant factors Sent from my iPhone > On May 26, 2016, at 1:29 PM, Jerry Callen wrote: > > (A very delayed follow-up on a thread from yesteryear...) > > tl;dr: In

Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.

(A very delayed follow-up on a thread from yesteryear...) tl;dr: In unauthorized code, ECBs are much faster than pause elements. I wrote a simple test program to compare the performance of WAIT/POST and pause elements. The program has two tasks and simply ping-pongs back and forth between them

Re: Space Calculation on z/OS sytems

Caveat: daily digestion leads to response delays... Didn't someone else, not long ago, have a problem with ISMF that turned out to be insufficient REGION= on the TSO session? mainframe1960 might want to make a quick side-trip for validation. > signature = 8 lines follows <

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

I added support in 2014 but have not had a motivation to create 999 and see what happens! -VMACCTLG and VMAC6156 were updated Nov 27, 2014. Support for GDGE, GDG Extended GDGLIMIT=999 in z/OS 2.2. New variable GATEXTND='E' flags the extended mode, new

Re: RFE's to consider

On Wed, 25 May 2016 11:26:29 -0500, Dyck, Lionel B. (TRA) wrote: >After asking for votes for 2 RFE's (TSO Pipes and StreamIO) I want to share >another RFE that could use your support. > >This RFE is asking IBM to provide full ISPF support for PDSE V2 Generations. >The link is: >

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

Barry, I have heard that the number of GDGs may be allowed to go beyond 255 generations. Do you have any insight on this? I am wondering how this enhancement may impact the GDG Wrap condition. I have seen in the z/OS V2.2 manuals: Extended format for generation data groups (GDGs): z/OS

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

An old change in MXG Software: Change 23.219 The ICF Catalog 05 record variable GATGEN should have VMAC6156 been input as , instead of one byte, and variable VMACCTLG GATWRAP='Y' is now set if the first bit of GATGEN is on, Aug 29, 2005 to mark that this GDG member has "wrapped";

Re: Getting timely dump out of LE

Have you tried the TRAP(OFF) parameter on the step? That usually works for me. You lose the LE formatted dump, but you do get the "standard" dump. Bill Hitefield Dino-Software Corporation 800.480.DINO 423.878.5660 www.dino-software.com -Original Message- From: IBM Mainframe Discussion

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

I do not know if this will help, but at CBTTAPE.ORG FILE 929 has a REXX function that could be of use. gds = REALNAME(the.gdg.name(+1)) Al Nims Systems Admin/Programmer 3 UFIT University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

"​I didn't think of that because in 35 years, I have _never_ seen anything other than V00 at the end.​" I looked into this a while back and, as far as I recall, only a single entry per generation can be cataloged within the GDG at any one time. IE., if you catalog G1234V01, then G1234V00 is no

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

catsearch just prints output in the order received from IGGCSI00. I have confirmed that LOCATE resolves existing relative GDG references correctly. Kirk Wolf Dovetailed Technologies http://dovetail.com On Thu, May 26, 2016 at 8:18 AM, John McKown wrote: > On Wed,

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

On Wed, May 25, 2016 at 6:37 PM, Lizette Koehler wrote: > John, > > Would this code account for a V01 - V99 ending in the GDG? > And would it handle the fact that the next GDG might not be a GVxx but > maybe a G0001Vxx? Remember GDG numbers at the back can wrap a

How to Calculate %USED for PDSE?

[Also posted to the Linked-In "Mainframe Assembler Professionals" group at http://linkd.in/1VjEST7 ] I wrote a program to create a report of DASD usage by scanning the UCB Table, then reading all the DSCBs from all the DASD Volumes for usage data and summing by DSN. The output is essentially the

Re: Video that might give you a chuckle

It's an interesting observation as I always chuckle when my American coworkers say parmlibe, or zee-OS iso zed-OS, ... The list goes on. Somehow we all know what we mean. Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Edward