We used to run with a mod to HCPDIA (CP DIAL command) which would accept a virtual device address on the target machine. If that address was already in use would keep incrementing the target address until an available address was found or issue an error message if the user ran out of beer. General users would not supply an address, starting with the first free vdev on the target server. "Special" users knew about the higher addresses with special capabilities and would have the "CP DIAL target higher_vdev" form of the command issued for them.
Since we no longer needed it I did not refit it from VM/ESA 240 or convert it to a CP Exit (probably Exit 1200), but it should not be hard. I can supply the outdated but nicely commented (so we knew where it belonged logically instead of just by source line numbers) source to anyone interested.
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
| "Tom Duerbusch"
<[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System" <[email protected]> 10/10/2006 03:09 PM
|
|
Can you now specify a range on the "DIAL" command? I've thought it was
first available.
Anyway, that doesn't help the coax attached devices. But interesting
idea.
Tom Duerbusch
THD Consulting
>>> [EMAIL PROTECTED] 10/10/2006 2:56 PM >>>
At Volusia Schools, we:
a) set up a higher range of virtual CUUs for VTAM with different
attributes. (In our case, different sizes.)
b) set VM/TCP to accept multiple ports for telnet.
c) changed the rexx proc that performs the DIAL VTAM to dial different
port ranges based on the IP port being connected to.
It was a simple change.
Tony Thigpen
-----Original Message -----
From: Tom Duerbusch
Sent: 10/10/2006 12:10 PM
> I'm in need of a solution to a weird problem....
>
> We have VM/VTAM control all of our real terminal controllers and the
VM
> TCPIP stack does a "DIAL VTAM" so all terminals get the same look
and
> feel. They come into a USSTAB (either the SNA or non-SNA version)
and
> are able to select the CICS system they want.
>
> The 12 VSE VTAMs only define the cross domain services and the CICS
> applids.
>
> The 29 CICS systems, all use autoinstall.
>
> That part is all simple.....
>
> Our production CICS systems for inhouse developed applications....
> well some of the applications were written in the mid '70s. I came
into
> the CICS world with CICS 1.4, and these applications may have been
> written for a prior CICS release. Anyway, they don't have
"attributes"
> specified in the BMS maps. The application programmers coded them
in
> the application program. i.e. they moved "what they thought" was
proper
> attribute bytes to their maps.
>
> This worked fine. That is for non-extended data stream devices.
And
> all of our VM/VTAM definations define all devices as non-EDS.
>
> Well, now I need EDS capable devices but only on certain CICS
regions.
>
> When I changed the VTAM devices to support EDS, we got all sorts of
> weird colors, blinking and reverse video on our old applications.
> Apparently, when the Cobol programmers created their attribute bytes
> (and it wasn't copy books, it is inline code that was redeveloped
with
> each new program...or so it seems), they only cared about the bits
they
> needed (highlight/normal) and the rest of the bits, didn't bother
> anything....until now.
>
> What I want to be able to do is, on a CICS by CICS basis, setup
whether
> that system can handle EDS. My understanding of the negoiation of
the
> bind, is when there are conflicts, they step down to the lowest
common
> attributes. I would rather not make changes to our current
production
> systems, but rather to the systems that need EDS. But I think those
two
> conditions are in direct conflict with each other.
>
> What are some good ways of making this type of change?
>
> Thanks
>
> Tom Duerbusch
> THD Consulting
>
>
The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
