what I understood is that you need an additional IP range because you run out of the old.
Now you've to consider what would you want to reach with the new subnet:
* Should all applications be autarkic from all others
* Should both subtnets be able to communicate with each other
* Are you considering in setting up a new LPAR or something (If your approach is to create a new LPAR or something, than you won't need all that. The OSA can be shared between them. So I suppose you don't want to create a new LPAR, right?)
Just after thinking one minute I see two alternatives (for sure there are more):
1. You just need to propagate a new range and the outside world must also propagate
2. You configure VLAN support with trunking on the switch ports
In both cases you'll need the support of the network stuff on your side.
This is something we also do.
Just as example: You've the range 172.16.0.0/16 for your z/OS. Now you need to expand that because you running out of IPs.
You also have a range of 192.168.0.0/24. You know this range is absolutly unused in the network. Than your network stuff can define routes in the routers where to reach that range (on the mainframe). The only thing you have to do is that you also have to propagate that range. This is the part of OMPROUTE (I consider you use OMPROUTE?).
With that solution you won't need a OSA port within the 192.168.0.0/24 subnet.
The other way, VLANs:
Example: You've actually the following interface definition (DEV/LINK/HOME, whatever):
Also in that case you need the other range, 192.168.0.0/24
When you define it as VLANs you have to delete the old interface definition and to redefine it with VLAN.
Please note: Your network support must offer you the VLAN IDs, they must match. They also must define the switch ports as trunc ports.
The new definition can look like that:
In that way you can define up to 32 VLANs, 32 different networks on the same OSA. Please note: For each VLAN you need a seperate DATAPATH in your TRL definition. The best way in the TRL would be to define one dev for read, one dev for write and the other devs for the CHPID as range for datapaths. VTAM will then allocate the devices. One per VLAN, one per IP Stack (if you have multiple stacks). All others are unused but can used dynamically without updating the TRL (by the way, that is possible on the fly).
At the end of that solution you need to add the new definitions to your OMPROUTE.
BTW: If you consider to cut the new IP range from the old (no access between them) you can also use VLANs. You can set up a firewall by using IP filtering. That wouldn't be practicable because when you logged on from one net or from the other one: The data is the same. I just want to say it is possible.
Hope that helped you?