David
What a relief to find a query where the outcome of the effort expended is
likely to be beneficial rather than having to deal with the depredations of
luddites!
-
Just so nobody else need bother to look it up, 08570003 means that the
secondary LU is not active, that is, there is no SSCP(VTAM) to LU session in
place which there would be if the LU had been activated by the SSCP.
> Can someone explain what is going on ?
I don't expect anyone would be able to deal with this problem without at least
some guidance on the structure of the program which imagines it is sending
the data to the "logical printer". I assume that the "logical printer" is
defined
to use LU type 1 with the SNA character set (SCS) character string but
without function management headers as is used with printers from the 3270
family - or - LU type 3, implicitly with the 3270 data, as is also used with
printers from the 3270 family.
Actually it strikes me that the program driving the "logical printer" is
behaving
rather well in that it was aware that the "buffers" it had already "tried" to
print
had not in fact been printed and so resent them when the session setup was
successful.
It may be that your background is the unreliable connectionless world of IP -
which some I have been dealing with lately inexplicably imagine is so far
superior to SNA that one is labelled a disgrace to try to imagine otherwise, a
sort of Taliban approach - sorry about that, it just came out! In that case it
may be a surprise for you that an SNA-based application will tend not tolerate
loss of data.
Anyhow we obviously need more information about your overall environment,
including perhaps the identity of the application which is driving the "logical
printer".
-
Meantime, when definitions are posted, I try to take the opportunity to make
any comments on what is specified which might be helpful.
Unravelling your APPL statement for the purposes of commenting:
NOMPRT01 APPL AUTH=NVPACE,
EAS=1,
PARSESS=NO,
MODETAB=ISTINCLM,
DLOGMOD=DSC2K,
SESSLIM=YES,
USSTAB=ISTINCDT
Since this APPL statement does not represent a "programmed operator", the
following operand is superfluous:
USSTAB[1]
Since this APPL statement represents a secondary application, the following
suboperand is superfluous:
AUTH=NVPACE[2]
Since the name of the mode table specified is the supplied mode table, the
following specification is superfluous:
MODETAB=ISTINCLM[3]
Since it is a "negative" specification where the "positive" implies additional
support and the "negative" specification is, as expected, the default, I tend
not to bother with specifications such as the following although it is not
strictly superfluous:
PARSESS=NO[4]
If your program is designed in such a way that you need one instance of your
program for each "logical printer" which I guess is very likely, the following
specification is not actually required but is very sensible in that a small
amount of storage is saved:
EAS=1
Also the following specification is very probably useful should your operations
or definitions get confused and another application driving a "logical printer"
tries to set up a session with the secondary LU supporting a "logical printer"
while it is already in session:
SESSLIM=YES
Finally, I see - and I should have checked this before offering the alternative
of either LU type 1 or LU type 3 - that you, in effect, specify that the
secondary LU is going to suggest that the BIND image should be the following:
*
* PRINTER WITH 2K BUFFER
*
123456789012345678901234567890123456789012345678901234567890123456
789012
........ ..... ...
DSC2K MODEENT
LOGMODE=DSC2K,FMPROF=X'03',TSPROF=X'03',PRIPROT=X'B1',*
SECPROT=X'90',COMPROT=X'3080',RUSIZES=X'8787', *
PSERVIC=X'030000000000185018507F00', *
APPNCOS=#CONNECT
This is a BIND image with is suggesting the use of an LU type 3 session as
indicated by the first byte of the "presentation services" field.
I can now reflect that it is just as well I am sniffing around inside your
definitions because I see the possibility for misunderstanding.
Note that the use of the word "buffer" in the comments relating to this mode
table entry has no direct connection with any buffers which may or may not
be used within the application program driving the "logical printer" nor within
the application program representing the "logical printer" - nor with the
implementation of a *physical* printer - although that would correspond to
the microcode within the physical printer.
What the "buffer" size mentioned in the comments does address is the buffers
provided in the earliest 3270 printers such as the 3284 and 3286 - I wonder
how long the "folk memory" will continue to be available in this list!
What is important for you is that, assuming the program driving the "logical
printer" respects completely the BIND image offered at the time the session is
established and does not just ignore all or part of it, your program will need
to
deal with an outbound request unit size of 1024, which corresponds to the
second byte of the RUSIZES operand, the "maximum RU size sent on the
normal flow by the primary half-session".
If you insist on the 1024 size, you can check in your program when the BIND
arrives that the specification in byte 11 (0 origin) is still X'87' and reject
the
session setup if it is not.
Note that an application program such as CICS as the primary LU may be
configured to ignore the specifications in the BIND image offered during
session setup and specify some values hard-coded during customization.
I was going on to refer to another limit specified in the "presentation
services"
field which is the set of logical "display" device dimensions, 24 rows by 80
columns, which maps to 1 920 bytes of data but the data stream used to
transport these characters could contain formatting, such as "set buffer
address" sequences, which would extend the size of the request unit data
conveying the up to 1 920 bytes of data.
It's actually this limit, the set of logical "display" device dimensions, to
which
the 2K, 2 x 1024 = 2048, mentioned in the comments - and contained within
the name of the mode table entry - refers.
In case you are thinking this is all a bit weird - and you are entitled to! -
you
need to know whence LU type 3 - and LU type 2, the "type" which relates to
3270 "display" devices - originated. Before SNA the 3270 family appeared as
both displays and printers and the same logic was used for both "display"
devices and "printer" devices for the purposes of building an image of what
was to be displayed or printed within the "hardware" buffer before the image
made its way to the technology of the device itself, pixel-generation for
displays (in general - I expect there were alternatives used by OEM devices at
least), and probably some sort of golfball printing mechanism in a sort of
typewriter without a keyboard for printers. I'm trying feebly to remember here
but I hope you get the "picture".
Getting back to your APPL statement, probably all you really need is the
following
NOMPRT01 APPL
EAS=1,DLOGMOD=DSC2K,SESSLIM=YES,PACING=0,VPACING=0
You'll note I have added the PACING operands with value 0. The mode table
entry has not specified the "pacing" operands, so the value of these
parameters in the corresponding BIND image will be 0. The specification of
pacing can be a bit complicated but one rule is easy: if you are using LU type
3 - and LU type 2 with its intended mode of use - you will not need any
pacing since the requirement for definite responses means that pacing has no
benefits and is superfluous.
However the default value for both the PACING and VPACING operands is
*not* 0 and so you need to specify 0 in order to guarantee not to have
useless pacing overhead.
If you decide - and well you might - that using LU type 3 is inefficient and
you
should really be using LU type 1, don't forget to return to the issue of pacing
since it will then be needed in order fully to exploit the possibility of
greater
efficiency.
I have just remembered - while setting up the footnotes - that you mentioned
TELNET. It may be that you have modelled your APPL statement on some
TELNET sample. Well, you will be able to see from the clarifications below that
the sample was wrong where I said it was wrong. Also now I know why I have
made much the same observations not so long ago - because they were for
some TELNET sample!
Oddly enough the TN3270E server in Communications Server for z/OS V1R12
has introduced an enhanced function which may require SESSLIM=NO -
although the manual descriptions haven't caught onto that yet - ho hum, par
for the course!
-
> Can someone explain what is going on ?
Another thought that comes to mind is that, if you really want a handle on
what is going on, your friend is the "complete PIU" (CPIU) option used in a
session trace of your session - and any related sessions - using NetView
Session Monitor (aka NLDM). I do hope your support staff have installed
NetView and its components. There are so many "holed" feet around from
failure so to do!
-
Chris Mason
[] All descriptions taken from the Communications Server SNA Resource
Definition Reference.
[1] USSTAB
...
Specifies a user-defined USS table that contains user-modified VTAM operator
commands and VTAM operator messages to be used by the program operator.
USSTAB applies only to a program operator application program (AUTH=PPO or
AUTH=SPO). It is ignored if you code it for an application program that is not
a program operator.
[2] AUTH=NVPACE (or AUTH=VPACE)
Determines whether this application program is subject to the VPACING
specifications of SLUs with which the program is in session. Coding NVPACE is
the same as coding VPACING=0 in the LU definition statements for all of
the SLUs with which the application program is in session. NVPACE is ignored
for same-domain local SNA logical units.
My additional comment: Your application program is the SLU (secondary LU)
and it is the program driving the "logical printer" which is the PLU (primary
LU)
in session with the SLU.
[3] MODETAB=ISTINCLM
... If you do not supply a logon mode table for the application program, on the
MODETAB operand, an IBM-supplied default logon mode table (ISTINCLM) is
used. ...
[4] PARSESS=NO
Restricts this application program to one LU-LU session, between itself and
another logical unit, at a time. VTAM uses netnames rather than CIDs if
PARSESS=NO.
PARSESS defaults to NO when APPC=NO.
On Mon, 14 Feb 2011 05:22:43 -0600, David Lesser
<dav...@splsoftware.com> wrote:
>I have written a VTAM application which is similar to Telnet. It's purpose is
>to 'trap' printouts which were sent
>By various VTAM applications to VTAM printers, and save them in a database.
>
>For example, I define the following :
>
>APPLNOM VBUILD TYPE=APPL
>
>* *
>NOMPRT01 APPL
>AUTH=NVPACE,EAS=1,PARSESS=NO,MODETAB=ISTINCLM, +
> DLOGMOD=DSC2K,SESSLIM=YES,USSTAB=ISTINCDT
>
>When my VTAM application is not active and I try to print, I get the
following :
>
>IST663I INIT OTHER REQUEST FAILED, SENSE=08570003
>IST664I REAL OLU=SAGNET.DAEFCO REAL DLU=SAGNET.NOMPRT01
>IST889I SID = CF237FFB2870626D
>IST264I REQUIRED RESOURCE NOMPRT01 NOT ACTIVE
>IST314I END
>
>This is correct. The problem is that when I start my VTAM application and
>print to NOMPRT01, I get both buffers !
>It seems that VTAM saves the first buffer somewhere, and when my
>application starts and does a RECEIVE, it gets
>The buffers that were printed (and failed) , and then the next buffer !!!
>
>Can someone explain what is going on ?
>
>Many thanks,
>David
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
