Good afternoon.
I am trying to use a 3278 model, 4 definition for my master
console. The manual
GC26-3792-8_OS_VS2_System_Generation_Reference_Release_3.8_Oct80
says that I can specify a 3278 model 4 (figure 8 part 2 of 2 on
page 29) but when I try that I get an mnote saying that it is
invalid.
CONSMST?
CONSOLE?????????????????????????????????????????????????????? C
??????????????
MCONS=010,????????????????????????????????????????????? C
??????????????
ALTCONS=009,??????????????????????????????????????????? C
??????????????
AREA=04,??????????????????????????????????????????????? C
??????????????
PFK=12,???????????????????????????????????????????????? C
?????????????? ROUTCDE=ALL?
MSTCONS?
IODEVICE????????????????????????????????????????????????????? C
??????????????
UNIT=3278,????????????????????????????????????????????? C
??????????????
MODEL=4,??????????????????????????????????????????????? C
??????????????
ADDRESS=010,??????????????????????????????????????????? C
??????????????
FEATURE=(EBKY3277,DOCHAR,KB78KEY,AUDALRM,NUMLOCK,?????? C
??????????????
SELPEN,PTREAD)????????????????????????????????????????? ?
*?
73+??? 5,* * * IEIIOD101 MSTCONS-UNIT VALUE 3278 INVALID
Can someone please direct me to where I have gone wrong?
Thanks
--
J. R. Michael Wegemer
Mississauga ON, Canada
-- J. R. Michael Wegemer Mississauga, ON
|
G'day,
If you look at the IODEVICE macro in SYS1.AGENLIB you can find mention of a device called 3277, but no mention of any 3278 device.
Accordingly, since the MNOTE you got points to the UNIT= value, we can safely conclude that there is no support for genning a 3278 device type.
Having concocted some console, VTAM and TSO usermods pertaining to 3270 devices in my travels, I believe it is true to say that the MVS 3.8J package from IBM which formed the basis of our TK systems has no support for 3270 screen sizes other than model-1 (12 lines, 40 columns) and model-2 (24 lines, 80- columns).
Often the original logic is to test for a screen size of 1920, and if not equal then treat as a model-1 screen size.? I like to change this to if less than 1920 then treat as model-1 otherwise treat as model-2.
While it has been possible to extend 3270 screen size support for VTAM and TSO/VTAM to arbitrary screen sizes (in practice, up to 16,384 screen buffer locations, even though 3270 architecture allows up to 255 columns and up to 255 lines), no such work has been carried out for console support (to my knowledge).
The buffer management for I/O data stream handling is greatly different when comparing VTAM and COMMTASK.? For VTAM, buffers are dynamically acquired as needed, whereas for COMMTASK there is a static screen image buffer for each 3270 (and 2066/3066 etc.) console with dimensions fixed at SYSGEN time.? (This was later changed by IBM in MVS/SP allowing the console set up to be specified in a CONSOLxx PARMLIB member which could be changed from IPL to IPL without an IOGEN.)
There is no technical reason why 3270 console support could not be enhanced, but so far no-one has done it (that I've heard about).
Enlarging screen sizes of VTAM terninals did present a major problem.? While sufficient VTAM buffers are acquired dynamically to hold long output data streams, longer input data streams caused buffer overrun which error recovery handled by disconnecting the terminal session.? This was fixed by increasing VTAM buffer capacity as specified in SYS1.VTAMLST(ATCSTR00).
I am reliably informed that the buffer overrun problem would not have occurred on real 370-era hardware because the timings of that equipment would have allowed PCI CCW logic enough time to procure more buffer space and update the channel program, thereby handling the longer-than-expected inbound data stream.
Anyway, I think you'll find that there is no support for 32-line or 43-line consoles in TK5.? VTAM support for large local non-SNA 3270 screens does not rely on any extensions being specified when the screen's UCB is genned - it is still genned as a 3277 from the OS p-o-v, so I wouldn't be surprised if large console screen size support - if ever implemented - also ignored the features specified in the relevant IODEVICE macro.
Cheers, Greg
toggle quoted message
Show quoted text
On 5/05/2024 4:18 am, Michael Wegemer via groups.io wrote: Good afternoon.
I am trying to use a 3278 model, 4 definition for my master console. The manual GC26-3792-8_OS_VS2_System_Generation_Reference_Release_3.8_Oct80 says that I can specify a 3278 model 4 (figure 8 part 2 of 2 on page 29) but when I try that I get an mnote saying that it is invalid.
CONSMST CONSOLE?????????????????????????????????????????????????????? C MCONS=010,????????????????????????????????????????????? C ALTCONS=009,??????????????????????????????????????????? C AREA=04,??????????????????????????????????????????????? C PFK=12,???????????????????????????????????????????????? C ?????????????? ROUTCDE=ALL
MSTCONS IODEVICE????????????????????????????????????????????????????? C UNIT=3278,????????????????????????????????????????????? C MODEL=4,??????????????????????????????????????????????? C ADDRESS=010,??????????????????????????????????????????? C FEATURE=(EBKY3277,DOCHAR,KB78KEY,AUDALRM,NUMLOCK,?????? C SELPEN,PTREAD) *
73+??? 5,* * * IEIIOD101 MSTCONS-UNIT VALUE 3278 INVALID
Can someone please direct me to where I have gone wrong?
Thanks
-- J. R. Michael Wegemer Mississauga ON, Canada -- J. R. Michael Wegemer Mississauga, ON
|
Thank you for your response. I believe you are correct. I tried
on both TK5 and the system generated by following Jay Maynard's
detailed instructions and got the same results. I also tried
changing the non console 3277 to 3278 and received a different
mnote saying that my unit value was invalid.
I am guessing that the sysgen manual that I have is incorrect or
mislabelled.
Again, Thank you.
On 2024-05-04 22:58, Greg Price via
groups.io wrote:
G'day,
If you look at the IODEVICE macro in SYS1.AGENLIB you can find
mention of a device called 3277, but no mention of any 3278
device.
Accordingly, since the MNOTE you got points to the UNIT= value, we
can safely conclude that there is no support for genning a 3278
device type.
Having concocted some console, VTAM and TSO usermods pertaining to
3270 devices in my travels, I believe it is true to say that the
MVS 3.8J package from IBM which formed the basis of our TK systems
has no support for 3270 screen sizes other than model-1 (12 lines,
40 columns) and model-2 (24 lines, 80- columns).
Often the original logic is to test for a screen size of 1920, and
if not equal then treat as a model-1 screen size.? I like to
change this to if less than 1920 then treat as model-1 otherwise
treat as model-2.
While it has been possible to extend 3270 screen size support for
VTAM and TSO/VTAM to arbitrary screen sizes (in practice, up to
16,384 screen buffer locations, even though 3270 architecture
allows up to 255 columns and up to 255 lines), no such work has
been carried out for console support (to my knowledge).
The buffer management for I/O data stream handling is greatly
different when comparing VTAM and COMMTASK.? For VTAM, buffers are
dynamically acquired as needed, whereas for COMMTASK there is a
static screen image buffer for each 3270 (and 2066/3066 etc.)
console with dimensions fixed at SYSGEN time.? (This was later
changed by IBM in MVS/SP allowing the console set up to be
specified in a CONSOLxx PARMLIB member which could be changed from
IPL to IPL without an IOGEN.)
There is no technical reason why 3270 console support could not be
enhanced, but so far no-one has done it (that I've heard about).
Enlarging screen sizes of VTAM terninals did present a major
problem.? While sufficient VTAM buffers are acquired dynamically
to hold long output data streams, longer input data streams caused
buffer overrun which error recovery handled by disconnecting the
terminal session.? This was fixed by increasing VTAM buffer
capacity as specified in SYS1.VTAMLST(ATCSTR00).
I am reliably informed that the buffer overrun problem would not
have occurred on real 370-era hardware because the timings of that
equipment would have allowed PCI CCW logic enough time to procure
more buffer space and update the channel program, thereby handling
the longer-than-expected inbound data stream.
Anyway, I think you'll find that there is no support for 32-line
or 43-line consoles in TK5.? VTAM support for large local non-SNA
3270 screens does not rely on any extensions being specified when
the screen's UCB is genned - it is still genned as a 3277 from the
OS p-o-v, so I wouldn't be surprised if large console screen size
support - if ever implemented - also ignored the features
specified in the relevant IODEVICE macro.
Cheers,
Greg
On 5/05/2024 4:18 am, Michael Wegemer via groups.io wrote:
Good afternoon.
I am trying to use a 3278 model, 4 definition for my master
console. The manual
GC26-3792-8_OS_VS2_System_Generation_Reference_Release_3.8_Oct80
says that I can specify a 3278 model 4 (figure 8 part 2 of 2 on
page 29) but when I try that I get an mnote saying that it is
invalid.
CONSMST
CONSOLE?????????????????????????????????????????????????????? C
MCONS=010,????????????????????????????????????????????? C
ALTCONS=009,??????????????????????????????????????????? C
AREA=04,??????????????????????????????????????????????? C
PFK=12,???????????????????????????????????????????????? C
?????????????? ROUTCDE=ALL
MSTCONS
IODEVICE????????????????????????????????????????????????????? C
UNIT=3278,????????????????????????????????????????????? C
MODEL=4,??????????????????????????????????????????????? C
ADDRESS=010,??????????????????????????????????????????? C
FEATURE=(EBKY3277,DOCHAR,KB78KEY,AUDALRM,NUMLOCK,?????? C
SELPEN,PTREAD)
*
73+??? 5,* * * IEIIOD101 MSTCONS-UNIT VALUE 3278 INVALID
Can someone please direct me to where I have gone wrong?
Thanks
--?
J. R. Michael Wegemer
Mississauga ON, Canada
--?
J. R. Michael Wegemer
Mississauga, ON
--
J. R. Michael Wegemer
Mississauga ON, Canada
-- J. R. Michael Wegemer Mississauga, ON
|
I think that even when using z/OS the nip console is limited to 80 x 24 and basic support. It is only when control passes to DIDOCS that other formats are supported. However, I cannot find a reference
for that.
Lennie
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of Michael Wegemer
Sent: 05 May 2024 04:16
To: [email protected]
Subject: Re: [H390-MVS] MVS 3.8j Master Console
?
Thank you for your response. I believe you are correct. I tried on both TK5 and the system generated by following Jay Maynard's detailed instructions and got the same results. I also tried changing the non console 3277 to 3278 and received a different mnote
saying that my unit value was invalid.
I am guessing that the sysgen manual that I have is incorrect or mislabelled.
Again, Thank you.
On 2024-05-04 22:58, Greg Price via groups.io wrote:
G'day,
If you look at the IODEVICE macro in SYS1.AGENLIB you can find mention of a device called 3277, but no mention of any 3278 device.
Accordingly, since the MNOTE you got points to the UNIT= value, we can safely conclude that there is no support for genning a 3278 device type.
Having concocted some console, VTAM and TSO usermods pertaining to 3270 devices in my travels, I believe it is true to say that the MVS 3.8J package from IBM which formed the basis of our TK systems has no support for 3270 screen sizes other than model-1 (12
lines, 40 columns) and model-2 (24 lines, 80- columns).
Often the original logic is to test for a screen size of 1920, and if not equal then treat as a model-1 screen size.? I like to change this to if less than 1920 then treat as model-1 otherwise treat as model-2.
While it has been possible to extend 3270 screen size support for VTAM and TSO/VTAM to arbitrary screen sizes (in practice, up to 16,384 screen buffer locations, even though 3270 architecture allows up to 255 columns and up to 255 lines), no such work has been
carried out for console support (to my knowledge).
The buffer management for I/O data stream handling is greatly different when comparing VTAM and COMMTASK.? For VTAM, buffers are dynamically acquired as needed, whereas for COMMTASK there is a static screen image buffer for each 3270 (and 2066/3066 etc.) console
with dimensions fixed at SYSGEN time.? (This was later changed by IBM in MVS/SP allowing the console set up to be specified in a CONSOLxx PARMLIB member which could be changed from IPL to IPL without an IOGEN.)
There is no technical reason why 3270 console support could not be enhanced, but so far no-one has done it (that I've heard about).
Enlarging screen sizes of VTAM terninals did present a major problem.? While sufficient VTAM buffers are acquired dynamically to hold long output data streams, longer input data streams caused buffer overrun which error recovery handled by disconnecting the
terminal session.? This was fixed by increasing VTAM buffer capacity as specified in SYS1.VTAMLST(ATCSTR00).
I am reliably informed that the buffer overrun problem would not have occurred on real 370-era hardware because the timings of that equipment would have allowed PCI CCW logic enough time to procure more buffer space and update the channel program, thereby handling
the longer-than-expected inbound data stream.
Anyway, I think you'll find that there is no support for 32-line or 43-line consoles in TK5.? VTAM support for large local non-SNA 3270 screens does not rely on any extensions being specified when the screen's UCB is genned - it is still genned as a 3277 from
the OS p-o-v, so I wouldn't be surprised if large console screen size support - if ever implemented - also ignored the features specified in the relevant IODEVICE macro.
Cheers,
Greg
On 5/05/2024 4:18 am, Michael Wegemer via groups.io wrote:
Good afternoon.
I am trying to use a 3278 model, 4 definition for my master console. The manual GC26-3792-8_OS_VS2_System_Generation_Reference_Release_3.8_Oct80 says that I can specify a 3278 model 4 (figure 8 part 2 of 2 on page 29) but when I try that I get an mnote saying
that it is invalid.
CONSMST CONSOLE?????????????????????????????????????????????????????? C
MCONS=010,????????????????????????????????????????????? C
ALTCONS=009,??????????????????????????????????????????? C
AREA=04,??????????????????????????????????????????????? C
PFK=12,???????????????????????????????????????????????? C
?????????????? ROUTCDE=ALL
MSTCONS IODEVICE????????????????????????????????????????????????????? C
UNIT=3278,????????????????????????????????????????????? C
MODEL=4,??????????????????????????????????????????????? C
ADDRESS=010,??????????????????????????????????????????? C
FEATURE=(EBKY3277,DOCHAR,KB78KEY,AUDALRM,NUMLOCK,?????? C
SELPEN,PTREAD)
*
73+??? 5,* * * IEIIOD101 MSTCONS-UNIT VALUE 3278 INVALID
Can someone please direct me to where I have gone wrong?
Thanks
--?
J. R. Michael Wegemer
Mississauga ON, Canada
--?
J. R. Michael Wegemer
Mississauga, ON
--
J. R. Michael Wegemer
Mississauga ON, Canada
--
J. R. Michael Wegemer
Mississauga, ON
|
I don't know that there is a reference, but z/OS definitely behaves that way.
When the CONSOLxx member was added in MVS/XA, the IOCP input?(which replaced the IOGEN for defining devices) also added the ability to specify MODEL=X on 3270s, and the system would query the device to find its actual size. In MVS/SP 1.3.x, you could specify UNIT=3278,MODEL=4 on the IODEVICE macro, but I'm pretty sure that's one of the many enhancements in MVS/SP. On Sun, May 5, 2024 at 7:13?AM Lennie Bradshaw via <lennie-bradshaw= [email protected]> wrote:
toggle quoted message
Show quoted text
I think that even when using z/OS the nip console is limited to 80 x 24 and basic support. It is only when control passes to DIDOCS that other formats are supported. However, I cannot find a reference
for that.
Lennie
?
?
Thank you for your response. I believe you are correct. I tried on both TK5 and the system generated by following Jay Maynard's detailed instructions and got the same results. I also tried changing the non console 3277 to 3278 and received a different mnote
saying that my unit value was invalid.
I am guessing that the sysgen manual that I have is incorrect or mislabelled.
Again, Thank you.
On 2024-05-04 22:58, Greg Price via wrote:
G'day,
If you look at the IODEVICE macro in SYS1.AGENLIB you can find mention of a device called 3277, but no mention of any 3278 device.
Accordingly, since the MNOTE you got points to the UNIT= value, we can safely conclude that there is no support for genning a 3278 device type.
Having concocted some console, VTAM and TSO usermods pertaining to 3270 devices in my travels, I believe it is true to say that the MVS 3.8J package from IBM which formed the basis of our TK systems has no support for 3270 screen sizes other than model-1 (12
lines, 40 columns) and model-2 (24 lines, 80- columns).
Often the original logic is to test for a screen size of 1920, and if not equal then treat as a model-1 screen size.? I like to change this to if less than 1920 then treat as model-1 otherwise treat as model-2.
While it has been possible to extend 3270 screen size support for VTAM and TSO/VTAM to arbitrary screen sizes (in practice, up to 16,384 screen buffer locations, even though 3270 architecture allows up to 255 columns and up to 255 lines), no such work has been
carried out for console support (to my knowledge).
The buffer management for I/O data stream handling is greatly different when comparing VTAM and COMMTASK.? For VTAM, buffers are dynamically acquired as needed, whereas for COMMTASK there is a static screen image buffer for each 3270 (and 2066/3066 etc.) console
with dimensions fixed at SYSGEN time.? (This was later changed by IBM in MVS/SP allowing the console set up to be specified in a CONSOLxx PARMLIB member which could be changed from IPL to IPL without an IOGEN.)
There is no technical reason why 3270 console support could not be enhanced, but so far no-one has done it (that I've heard about).
Enlarging screen sizes of VTAM terninals did present a major problem.? While sufficient VTAM buffers are acquired dynamically to hold long output data streams, longer input data streams caused buffer overrun which error recovery handled by disconnecting the
terminal session.? This was fixed by increasing VTAM buffer capacity as specified in SYS1.VTAMLST(ATCSTR00).
I am reliably informed that the buffer overrun problem would not have occurred on real 370-era hardware because the timings of that equipment would have allowed PCI CCW logic enough time to procure more buffer space and update the channel program, thereby handling
the longer-than-expected inbound data stream.
Anyway, I think you'll find that there is no support for 32-line or 43-line consoles in TK5.? VTAM support for large local non-SNA 3270 screens does not rely on any extensions being specified when the screen's UCB is genned - it is still genned as a 3277 from
the OS p-o-v, so I wouldn't be surprised if large console screen size support - if ever implemented - also ignored the features specified in the relevant IODEVICE macro.
Cheers,
Greg
On 5/05/2024 4:18 am, Michael Wegemer via wrote:
Good afternoon.
I am trying to use a 3278 model, 4 definition for my master console. The manual GC26-3792-8_OS_VS2_System_Generation_Reference_Release_3.8_Oct80 says that I can specify a 3278 model 4 (figure 8 part 2 of 2 on page 29) but when I try that I get an mnote saying
that it is invalid.
CONSMST CONSOLE?????????????????????????????????????????????????????? C
MCONS=010,????????????????????????????????????????????? C
ALTCONS=009,??????????????????????????????????????????? C
AREA=04,??????????????????????????????????????????????? C
PFK=12,???????????????????????????????????????????????? C
?????????????? ROUTCDE=ALL
MSTCONS IODEVICE????????????????????????????????????????????????????? C
UNIT=3278,????????????????????????????????????????????? C
MODEL=4,??????????????????????????????????????????????? C
ADDRESS=010,??????????????????????????????????????????? C
FEATURE=(EBKY3277,DOCHAR,KB78KEY,AUDALRM,NUMLOCK,?????? C
SELPEN,PTREAD)
*
73+??? 5,* * * IEIIOD101 MSTCONS-UNIT VALUE 3278 INVALID
Can someone please direct me to where I have gone wrong?
Thanks
--?
J. R. Michael Wegemer
Mississauga ON, Canada
--?
J. R. Michael Wegemer
Mississauga, ON
--
J. R. Michael Wegemer
Mississauga ON, Canada
--
J. R. Michael Wegemer
Mississauga, ON
|
The manual you are using is too new for MVS 3.8J. If you look at the Summary of? Amendments starting on page vii it states it was updated for DF/EF Rel 1 and MVS/SP JES3 and JES2 The text indicates that support for 3278 model 1, 2, 2A 3, 4? and 3279. models at .
Since they are program products they are licensed software and not available without purchasing a license. Bitsavers appears to have only -1 and -8 versions,
Laddie Hanus
.? ?
On Saturday, May 4, 2024 at 10:16:02 PM CDT, Michael Wegemer <michael.wegemer@...> wrote:
Thank you for your response. I believe you are correct. I tried
on both TK5 and the system generated by following Jay Maynard's
detailed instructions and got the same results. I also tried
changing the non console 3277 to 3278 and received a different
mnote saying that my unit value was invalid.
I am guessing that the sysgen manual that I have is incorrect or
mislabelled.
Again, Thank you.
On 2024-05-04 22:58, Greg Price via
groups.io wrote:
G'day,
If you look at the IODEVICE macro in SYS1.AGENLIB you can find
mention of a device called 3277, but no mention of any 3278
device.
Accordingly, since the MNOTE you got points to the UNIT= value, we
can safely conclude that there is no support for genning a 3278
device type.
Having concocted some console, VTAM and TSO usermods pertaining to
3270 devices in my travels, I believe it is true to say that the
MVS 3.8J package from IBM which formed the basis of our TK systems
has no support for 3270 screen sizes other than model-1 (12 lines,
40 columns) and model-2 (24 lines, 80- columns).
Often the original logic is to test for a screen size of 1920, and
if not equal then treat as a model-1 screen size.? I like to
change this to if less than 1920 then treat as model-1 otherwise
treat as model-2.
While it has been possible to extend 3270 screen size support for
VTAM and TSO/VTAM to arbitrary screen sizes (in practice, up to
16,384 screen buffer locations, even though 3270 architecture
allows up to 255 columns and up to 255 lines), no such work has
been carried out for console support (to my knowledge).
The buffer management for I/O data stream handling is greatly
different when comparing VTAM and COMMTASK.? For VTAM, buffers are
dynamically acquired as needed, whereas for COMMTASK there is a
static screen image buffer for each 3270 (and 2066/3066 etc.)
console with dimensions fixed at SYSGEN time.? (This was later
changed by IBM in MVS/SP allowing the console set up to be
specified in a CONSOLxx PARMLIB member which could be changed from
IPL to IPL without an IOGEN.)
There is no technical reason why 3270 console support could not be
enhanced, but so far no-one has done it (that I've heard about).
Enlarging screen sizes of VTAM terninals did present a major
problem.? While sufficient VTAM buffers are acquired dynamically
to hold long output data streams, longer input data streams caused
buffer overrun which error recovery handled by disconnecting the
terminal session.? This was fixed by increasing VTAM buffer
capacity as specified in SYS1.VTAMLST(ATCSTR00).
I am reliably informed that the buffer overrun problem would not
have occurred on real 370-era hardware because the timings of that
equipment would have allowed PCI CCW logic enough time to procure
more buffer space and update the channel program, thereby handling
the longer-than-expected inbound data stream.
Anyway, I think you'll find that there is no support for 32-line
or 43-line consoles in TK5.? VTAM support for large local non-SNA
3270 screens does not rely on any extensions being specified when
the screen's UCB is genned - it is still genned as a 3277 from the
OS p-o-v, so I wouldn't be surprised if large console screen size
support - if ever implemented - also ignored the features
specified in the relevant IODEVICE macro.
Cheers,
Greg
On 5/05/2024 4:18 am, Michael Wegemer via groups.io wrote:
Good afternoon.
I am trying to use a 3278 model, 4 definition for my master
console. The manual
GC26-3792-8_OS_VS2_System_Generation_Reference_Release_3.8_Oct80
says that I can specify a 3278 model 4 (figure 8 part 2 of 2 on
page 29) but when I try that I get an mnote saying that it is
invalid.
CONSMST
CONSOLE?????????????????????????????????????????????????????? C
MCONS=010,????????????????????????????????????????????? C
ALTCONS=009,??????????????????????????????????????????? C
AREA=04,??????????????????????????????????????????????? C
PFK=12,???????????????????????????????????????????????? C
?????????????? ROUTCDE=ALL
MSTCONS
IODEVICE????????????????????????????????????????????????????? C
UNIT=3278,????????????????????????????????????????????? C
MODEL=4,??????????????????????????????????????????????? C
ADDRESS=010,??????????????????????????????????????????? C
FEATURE=(EBKY3277,DOCHAR,KB78KEY,AUDALRM,NUMLOCK,?????? C
SELPEN,PTREAD)
*
73+??? 5,* * * IEIIOD101 MSTCONS-UNIT VALUE 3278 INVALID
Can someone please direct me to where I have gone wrong?
Thanks
--?
J. R. Michael Wegemer
Mississauga ON, Canada
--?
J. R. Michael Wegemer
Mississauga, ON
--
J. R. Michael Wegemer
Mississauga ON, Canada
-- J. R. Michael Wegemer Mississauga, ON
|
Thank you, I missed that part.
toggle quoted message
Show quoted text
On Sun., May 5, 2024, 9:27 a.m. laddiehanus via , <laddiehanus= [email protected]> wrote:
The manual you are using is too new for MVS 3.8J. If you look at the Summary of? Amendments starting on page vii it states it was updated for DF/EF Rel 1 and MVS/SP JES3 and JES2 The text indicates that support for 3278 model 1, 2, 2A 3, 4? and 3279. models at .
Since they are program products they are licensed software and not available without purchasing a license. Bitsavers appears to have only -1 and -8 versions,
Laddie Hanus
.? ?
Thank you for your response. I believe you are correct. I tried
on both TK5 and the system generated by following Jay Maynard's
detailed instructions and got the same results. I also tried
changing the non console 3277 to 3278 and received a different
mnote saying that my unit value was invalid.
I am guessing that the sysgen manual that I have is incorrect or
mislabelled.
Again, Thank you.
On 2024-05-04 22:58, Greg Price via
wrote:
G'day,
If you look at the IODEVICE macro in SYS1.AGENLIB you can find
mention of a device called 3277, but no mention of any 3278
device.
Accordingly, since the MNOTE you got points to the UNIT= value, we
can safely conclude that there is no support for genning a 3278
device type.
Having concocted some console, VTAM and TSO usermods pertaining to
3270 devices in my travels, I believe it is true to say that the
MVS 3.8J package from IBM which formed the basis of our TK systems
has no support for 3270 screen sizes other than model-1 (12 lines,
40 columns) and model-2 (24 lines, 80- columns).
Often the original logic is to test for a screen size of 1920, and
if not equal then treat as a model-1 screen size.? I like to
change this to if less than 1920 then treat as model-1 otherwise
treat as model-2.
While it has been possible to extend 3270 screen size support for
VTAM and TSO/VTAM to arbitrary screen sizes (in practice, up to
16,384 screen buffer locations, even though 3270 architecture
allows up to 255 columns and up to 255 lines), no such work has
been carried out for console support (to my knowledge).
The buffer management for I/O data stream handling is greatly
different when comparing VTAM and COMMTASK.? For VTAM, buffers are
dynamically acquired as needed, whereas for COMMTASK there is a
static screen image buffer for each 3270 (and 2066/3066 etc.)
console with dimensions fixed at SYSGEN time.? (This was later
changed by IBM in MVS/SP allowing the console set up to be
specified in a CONSOLxx PARMLIB member which could be changed from
IPL to IPL without an IOGEN.)
There is no technical reason why 3270 console support could not be
enhanced, but so far no-one has done it (that I've heard about).
Enlarging screen sizes of VTAM terninals did present a major
problem.? While sufficient VTAM buffers are acquired dynamically
to hold long output data streams, longer input data streams caused
buffer overrun which error recovery handled by disconnecting the
terminal session.? This was fixed by increasing VTAM buffer
capacity as specified in SYS1.VTAMLST(ATCSTR00).
I am reliably informed that the buffer overrun problem would not
have occurred on real 370-era hardware because the timings of that
equipment would have allowed PCI CCW logic enough time to procure
more buffer space and update the channel program, thereby handling
the longer-than-expected inbound data stream.
Anyway, I think you'll find that there is no support for 32-line
or 43-line consoles in TK5.? VTAM support for large local non-SNA
3270 screens does not rely on any extensions being specified when
the screen's UCB is genned - it is still genned as a 3277 from the
OS p-o-v, so I wouldn't be surprised if large console screen size
support - if ever implemented - also ignored the features
specified in the relevant IODEVICE macro.
Cheers,
Greg
On 5/05/2024 4:18 am, Michael Wegemer via wrote:
Good afternoon.
I am trying to use a 3278 model, 4 definition for my master
console. The manual
GC26-3792-8_OS_VS2_System_Generation_Reference_Release_3.8_Oct80
says that I can specify a 3278 model 4 (figure 8 part 2 of 2 on
page 29) but when I try that I get an mnote saying that it is
invalid.
CONSMST
CONSOLE?????????????????????????????????????????????????????? C
MCONS=010,????????????????????????????????????????????? C
ALTCONS=009,??????????????????????????????????????????? C
AREA=04,??????????????????????????????????????????????? C
PFK=12,???????????????????????????????????????????????? C
?????????????? ROUTCDE=ALL
MSTCONS
IODEVICE????????????????????????????????????????????????????? C
UNIT=3278,????????????????????????????????????????????? C
MODEL=4,??????????????????????????????????????????????? C
ADDRESS=010,??????????????????????????????????????????? C
FEATURE=(EBKY3277,DOCHAR,KB78KEY,AUDALRM,NUMLOCK,?????? C
SELPEN,PTREAD)
*
73+??? 5,* * * IEIIOD101 MSTCONS-UNIT VALUE 3278 INVALID
Can someone please direct me to where I have gone wrong?
Thanks
--?
J. R. Michael Wegemer
Mississauga ON, Canada
--?
J. R. Michael Wegemer
Mississauga, ON
--
J. R. Michael Wegemer
Mississauga ON, Canada
-- J. R. Michael Wegemer Mississauga, ON
-- J. R. Michael Wegemer Mississauga, ON
|