ca.portal.admin

Re:Re: DCLOG Message

Discussion created by ca.portal.admin on Mar 16, 2007
Hi Steve,
We get these messages on one of our systems. I have tracked them down to
terminals used by a group of robotic users. I believe that their
terminal emulation leaves something to be desired.
I am not aware that it causes any problems apart from the snaps on the
log when they connect.

Steve Terry
BT

'This post represents the views of the author and does not necessarily
accurately represent the views of BT.'
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ Registered in
England no. 1800000

This electronic message contains information from British
Telecommunications plc which may be privileged and confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient, be aware that any
disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic message
in error, please notify us by telephone or e-mail (to the number or
address above) immediately.-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of Harmeson, Steve
Sent: 15 March 2007 14:19
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: DCLOG Message

I was perusing one of my logs and happened tp run across this
Query/Repliy: invalid input buffer message


07:02 IDMS DC999009 V1 USER LLS04 LOGGED ON TERMINAL LTVTM055 AT
07:02:26.07
07:02 IDMS DC999009 V1 USER EAP04 LOGGED ON TERMINAL LTVTM057 AT
07:02:35.23
07:02 Query/Reply: invalid input buffer

07:02 143C2000 40404040 40404040 7D404000 00000000 * ' .....*

07:02 END OF SNAP

07:02 IDMS DC999009 V1 USER BJO04 LOGGED ON TERMINAL LTVTM056 AT
07:02:39.45
07:02 IDMS DC999009 V1 USER DMA12 LOGGED ON TERMINAL LTVTM058 AT
07:02:42.88
07:03 IDMS DC999009 V1 USER MLR10 LOGGED ON TERMINAL LTVTM059 AT
07:03:06.64
07:03 IDMS DC259001 V1 USER BJE02 SIGNED OFF LTERM LTVTM036 AT
07:03:11.20 07


I have snap turned off ( its production) so I am not sure where this is
is coming from. I searched the DISTMAC but nothing really turned up.
Has anyone seen this before?

Thanks,
Steve Harmeson
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
"CA-WORLD sessions, ENQ/DEQ in DC COBOL and miscellany..."
"Hello fellow IDMSers. Has anyone noticed a dearth on the published CA-
WORLD schedule of IDMS sessions? All I could see was some education over
the weekend. I did see plenty of Datacom sessions however...
Is the final CA-WORLD session schedule updated? Or did I just miss the
sessions somehow?

Also, we have a problem brewing here in our IDMS shop. Details as follows.
1) we a a UCFCICS/UCFDESPL shop (on REL 16 SP0)
2) we use MacKinney VVP and JQP
3) we have a common print routine subsystem in DC-COBOL that all programs
pass their prints to.
4) the IDMS prints go to a Transient Data Queue that triggers the UCFDESPL
print pgm to run EXEC CICS SEND TERMINAL cmds
5) MacKinney VVP picks up CICS/VTAM prints for further disposition to JQP.
6) Sometimes VVP gets confused when gathering the prints when prints are
simultaneous
and combines multiple prints in one file and in the process loses some(or
a) control character (form feed).
7) our team in zOS Tech Support is taking this issue up with MacKinney but
the users are getting pretty worked up in the meanwhile.
8) this problem has been occurring for a few months now and we are still
working at the problem.

In the meantime, we would like to try single threading the print routine
subsystem DC-COBOL program I mentioned in step 3.
In a CICS COBOL program I would have threaded by using a EXEC CICS ENQ and
DEQ with the same
logical resource name used in the program i wanted to thread on.
I don't see ENQ's and DEQ's equivalent commands for threading in IDMS DC-
COBOL.
Any suggestions on how to do this single threading?

P.S. please don't offer suggestions on how to change steps 1-6 (they're
out of my control and things are moving too slow on that front to solve
this enduser-facing critical print problem). I'd like to try my threading
idea first...

Regards,

Mark Casagrande
Lead Systems Analyst
City of Tampa, Florida
Dept of Technology and Innovation
Office: (813) 274-8484
Email: Mark.Casagrande@ci.tampa.fl.us
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
"Re: CA-WORLD sessions, ENQ/DEQ in DC COBOL and miscellany..."
"Mark,

You missed a bunch....

IDMS has 19 sessions and 1 day of free education

Bob Wiklund
Tiburon Technologies
623 594-6022


"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
"Re: CA-WORLD sessions, ENQ/DEQ in DC COBOL and miscellany..."
"As Gary said, if you want to single thread the second level program
(if I understood your post, this is where the write printer is), then
every caller of the program needs to have an ENQUEUE prior to the call
and a DEQUEUE following the call, if you plan to single thread using
this method. You can also single thread the program using a sysgen
option on the program statement.

An alternative would be to put ENQUEUE/DEQUEUE logic in the write
printer program, but this means that the program could be running on
more than one terminal, all but one of which would be in a wait on the
resource ID while the holder of the resource is processing.

Either could work, but each has a different amount of overhead.

Also, regarding the ""ID known to DC"", this is referring to the ID used
in the ENQUEUE/DEQUEUE command. You create this id in your program and
issue an ENQUEUE. The first time you issue the request, DC sees that
the id isn't known so it creates the id. The second request for the
id, while the first request is active will find the ""ID known to DC""
and cause the second requestor to go into a wait for the first to
complete.

So, the ID eventually gets known to DC, but not until the first time
you use it.

When I get into the office in the morning I will send you my program.

Chuck

kilrathi <at> frontiernet <dot> net


Quoting Mark Casagrande <Mark.Casagrande@CI.TAMPA.FL.US>:
TYVM Chuck. I am in your debt and would very much appreciate any samples
and validation of our approach.
What did you think about Gary's comment on single threading inside the
called DC-COBOL vs b4 the call?
Have you ever heard about this approach causing any probs threading
like this in DC-COBOL...
kilrathi@FRONTIERNET.NET 3/21/2007 7:55:17 PM >>>
Mark,

I have some code set up to use ENQUEUE and DEQUEUE if you are
interested in a sample. Send me an email off-list and I will send it
to you.

Chuck

kilrathi <at> frontiernet <dot> net

Quoting Mark Casagrande <Mark.Casagrande@CI.TAMPA.FL.US>:
TYVM Gary, i appreciate the explanation(any and all) on UCF and DC.
When
I joined the IDMS group
here at the COT(city of tampa) 5 years ago i was always rather foggy
on
what it meant
to not have the ""DC"" option. As a MVS and CICS lifer i was very
familiar with ENQ/DEQ and
never understood the IDMS ramifications of not having ""DC"" and using
""UCFCICS"".
Can you and the gang clarify the history of this whole (DC or no DC)
thing for me a bit?
And color me grateful to the list and to all who have replied!!!!!
You
guys rule!!!
P.S.1 Chris - tell Carmen and company that we here at the COT say a
big HI and we're preparing our DataDirect approach!
P.S.2 THe manual really does seem to be saying that the resource id
needs to be gen'd.
In CICS we never had to gen anything, just made up a logical name
and
used it in the right
common program to insure the threading...

Regards to all IDMS friends and see ya at da Woild!

Mark Casagrande
Lead Systems Analyst
City of Tampa, Florida
Dept of Technology and Innovation
Office: (813) 274-8484
Email: Mark.Casagrande@ci.tampa.fl.us
Cherlet.Gary@SAUGOV.SA.GOV.AU 3/21/2007 6:53:13 PM >>>
UCF is a part of IDMS-DC - so if you are doing DC-Cobol WRITE
PRINTERS
you will be able to do DC-Cobol ENQ/DEQ. The resource names do NOT
need
to be defined in the sysgen - they are what you chose within your
site
to represent the resource that you are trying to ENQ on. For example
Resource Name 'VVPJQP' Resource length 6 might reflect the DC-Cobol
Print program.

What you need to decide though is whether to single-thread access to
the
program itself, in which case you would need to ENQ/DEQ before you
CALL
or TRANSFER CONTROL ... RETURN - or whether the ENQ/DEQ will be
within
the ""called sub-routine"" (obviously less change). We tried
single-threading through a DC-Cobol by defining it as NONCONCURRENT
-
but for long standing historical reasons, explained to us by CA when
we
opened an issue, this ONLY works with DC-Assembler programs. Our
issue
was also to do with ""printing"" - but in our case using the CA-Spool
API
from DC-Cobol in a multi-tasking IDMS-DC environment.

HTH - cheers - Gary

-----Original Message-----
From: IDMS Public Discussion Forum
[mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of Mark Casagrande
Sent: Thursday, 22 March 2007 9:06
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: CA-WORLD sessions, ENQ/DEQ in DC COBOL and
miscellany...
TYVM Chris we appreciate it. We saw the ENQUEUE/DEQ references in
the
DML Reference books but were afraid it was a DC only thing and we
are
a
UCF shop(no DC). If it is not a DC-only thing, can you tell us how
to
config the resource names? (apparently they have to be gen'd)

Regards,
Mark

=========================================================
See section 5.32 ENQUEUE and section 5.26 DEQUEUE in the 16.0
Advantage
CA-IDMS DML Reference - COBOL.

-----Original Message-----
From: IDMS Public Discussion Forum
[mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of Mark Casagrande
Sent: Wednesday, March 21, 2007 4:41 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: [IDMS-L] CA-WORLD sessions, ENQ/DEQ in DC COBOL and
miscellany...

Hello fellow IDMSers. Has anyone noticed a dearth on the published
CA-
WORLD schedule of IDMS sessions? All I could see was some education
over
the weekend. I did see plenty of Datacom sessions however...
Is the final CA-WORLD session schedule updated? Or did I just miss
the
sessions somehow?

Also, we have a problem brewing here in our IDMS shop. Details as
follows.
1) we a a UCFCICS/UCFDESPL shop (on REL 16 SP0)
2) we use MacKinney VVP and JQP
3) we have a common print routine subsystem in DC-COBOL that all
programs pass their prints to.
4) the IDMS prints go to a Transient Data Queue that triggers the
UCFDESPL print pgm to run EXEC CICS SEND TERMINAL cmds
5) MacKinney VVP picks up CICS/VTAM prints for further disposition
to
JQP.
6) Sometimes VVP gets confused when gathering the prints when prints
are
simultaneous and combines multiple prints in one file and in the
process
loses some(or
a) control character (form feed).
7) our team in zOS Tech Support is taking this issue up with
MacKinney
but the users are getting pretty worked up in the meanwhile.
8) this problem has been occurring for a few months now and we are
still
working at the problem.

In the meantime, we would like to try single threading the print
routine
subsystem DC-COBOL program I mentioned in step 3.
In a CICS COBOL program I would have threaded by using a EXEC CICS
ENQ
and DEQ with the same logical resource name used in the program i
wanted
to thread on.
I don't see ENQ's and DEQ's equivalent commands for threading in
IDMS
DC-
COBOL.
Any suggestions on how to do this single threading?

P.S. please don't offer suggestions on how to change steps 1-6
(they're
out of my control and things are moving too slow on that front to
solve
this enduser-facing critical print problem). I'd like to try my
threading idea first...

Regards,

Mark Casagrande
Lead Systems Analyst
City of Tampa, Florida
Dept of Technology and Innovation
Office: (813) 274-8484
Email: Mark.Casagrande@ci.tampa.fl.us
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
"Re: CA-WORLD sessions, ENQ/DEQ in DC COBOL and miscellany..."
"TYVM Chuck. I am in your debt and would very much appreciate any samples
and validation of our approach.
What did you think about Gary's comment on single threading inside the
called DC-COBOL vs b4 the call?
Have you ever heard about this approach causing any probs threading
like this in DC-COBOL...
kilrathi@FRONTIERNET.NET 3/21/2007 7:55:17 PM >>>
Mark,

I have some code set up to use ENQUEUE and DEQUEUE if you are
interested in a sample. Send me an email off-list and I will send it
to you.

Chuck

kilrathi <at> frontiernet <dot> net

Quoting Mark Casagrande <Mark.Casagrande@CI.TAMPA.FL.US>:
TYVM Gary, i appreciate the explanation(any and all) on UCF and DC.
When
I joined the IDMS group
here at the COT(city of tampa) 5 years ago i was always rather foggy
on
what it meant
to not have the ""DC"" option. As a MVS and CICS lifer i was very
familiar with ENQ/DEQ and
never understood the IDMS ramifications of not having ""DC"" and using
""UCFCICS"".
Can you and the gang clarify the history of this whole (DC or no DC)
thing for me a bit?
And color me grateful to the list and to all who have replied!!!!!
You
guys rule!!!
P.S.1 Chris - tell Carmen and company that we here at the COT say a
big HI and we're preparing our DataDirect approach!
P.S.2 THe manual really does seem to be saying that the resource id
needs to be gen'd.
In CICS we never had to gen anything, just made up a logical name
and
used it in the right
common program to insure the threading...

Regards to all IDMS friends and see ya at da Woild!

Mark Casagrande
Lead Systems Analyst
City of Tampa, Florida
Dept of Technology and Innovation
Office: (813) 274-8484
Email: Mark.Casagrande@ci.tampa.fl.us
Cherlet.Gary@SAUGOV.SA.GOV.AU 3/21/2007 6:53:13 PM >>>
UCF is a part of IDMS-DC - so if you are doing DC-Cobol WRITE
PRINTERS
you will be able to do DC-Cobol ENQ/DEQ. The resource names do NOT
need
to be defined in the sysgen - they are what you chose within your
site
to represent the resource that you are trying to ENQ on. For example
Resource Name 'VVPJQP' Resource length 6 might reflect the DC-Cobol
Print program.

What you need to decide though is whether to single-thread access to
the
program itself, in which case you would need to ENQ/DEQ before you
CALL
or TRANSFER CONTROL ... RETURN - or whether the ENQ/DEQ will be
within
the ""called sub-routine"" (obviously less change). We tried
single-threading through a DC-Cobol by defining it as NONCONCURRENT
-
but for long standing historical reasons, explained to us by CA when
we
opened an issue, this ONLY works with DC-Assembler programs. Our
issue
was also to do with ""printing"" - but in our case using the CA-Spool
API
from DC-Cobol in a multi-tasking IDMS-DC environment.

HTH - cheers - Gary

-----Original Message-----
From: IDMS Public Discussion Forum
[mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of Mark Casagrande
Sent: Thursday, 22 March 2007 9:06
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: CA-WORLD sessions, ENQ/DEQ in DC COBOL and
miscellany...
>
TYVM Chris we appreciate it. We saw the ENQUEUE/DEQ references in
the
DML Reference books but were afraid it was a DC only thing and we
are
a
UCF shop(no DC). If it is not a DC-only thing, can you tell us how
to
config the resource names? (apparently they have to be gen'd)

Regards,
Mark

=========================================================
See section 5.32 ENQUEUE and section 5.26 DEQUEUE in the 16.0
Advantage
CA-IDMS DML Reference - COBOL.

-----Original Message-----
From: IDMS Public Discussion Forum
[mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of Mark Casagrande
Sent: Wednesday, March 21, 2007 4:41 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: [IDMS-L] CA-WORLD sessions, ENQ/DEQ in DC COBOL and
miscellany...

Hello fellow IDMSers. Has anyone noticed a dearth on the published
CA-
WORLD schedule of IDMS sessions? All I could see was some education
over
the weekend. I did see plenty of Datacom sessions however...
Is the final CA-WORLD session schedule updated? Or did I just miss
the
sessions somehow?

Also, we have a problem brewing here in our IDMS shop. Details as
follows.
1) we a a UCFCICS/UCFDESPL shop (on REL 16 SP0)
2) we use MacKinney VVP and JQP
3) we have a common print routine subsystem in DC-COBOL that all
programs pass their prints to.
4) the IDMS prints go to a Transient Data Queue that triggers the
UCFDESPL print pgm to run EXEC CICS SEND TERMINAL cmds
5) MacKinney VVP picks up CICS/VTAM prints for further disposition
to
JQP.
6) Sometimes VVP gets confused when gathering the prints when prints
are
simultaneous and combines multiple prints in one file and in the
process
loses some(or
a) control character (form feed).
7) our team in zOS Tech Support is taking this issue up with
MacKinney
but the users are getting pretty worked up in the meanwhile.
8) this problem has been occurring for a few months now and we are
still
working at the problem.

In the meantime, we would like to try single threading the print
routine
subsystem DC-COBOL program I mentioned in step 3.
In a CICS COBOL program I would have threaded by using a EXEC CICS
ENQ
and DEQ with the same logical resource name used in the program i
wanted
to thread on.
I don't see ENQ's and DEQ's equivalent commands for threading in
IDMS
DC-
COBOL.
Any suggestions on how to do this single threading?

P.S. please don't offer suggestions on how to change steps 1-6
(they're
out of my control and things are moving too slow on that front to
solve
this enduser-facing critical print problem). I'd like to try my
threading idea first...

Regards,

Mark Casagrande
Lead Systems Analyst
City of Tampa, Florida
Dept of Technology and Innovation
Office: (813) 274-8484
Email: Mark.Casagrande@ci.tampa.fl.us
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
"Re: CA-WORLD sessions, ENQ/DEQ in DC COBOL and miscellany..."
"First off - Gary - dude U also rule!!!
Second - i love that oziua.shorturl.com site! TYVM for putting it up!
Third - OK I believe ya on the logical enq rsource-id being any old
literal just as it is in CICS, but it did say as follows in the Softcopy
manual under ENQUEUE in the DML Reference COBOL:
====================================================
NAME Specifies the ID associated with a resource.
Multiple resource specifications must be separated by at least one
blank.

resource-id Specifies the symbolic name of a user-defined field that
contains the resource ID. The resource ID must be the name of a resource
defined to the DC system. Any resource name can be specified, provided
that all programs that access the resource use the same name.
==================================================
That's where i got that DC system stuff. But i will never mention it
again i swear!!!

Also, while I'm waiting for more hisrtory from Gary-
to clarify some old ""DC"" references - how do i have DC-COBOL
but have never paid for the ""DC"" Option of IDMS?
What are some of the biggest drwabacks to having not purchased the ""DC""
otion for IDMS?

Regards from your grateful poster friend,
BigHouse

Mark Casagrande
Lead Systems Analyst
City of Tampa, Florida
Dept of Technology and Innovation
Office: (813) 274-8484
Email: Mark.Casagrande@ci.tampa.fl.us
Cherlet.Gary@SAUGOV.SA.GOV.AU 3/21/2007 7:44:19 PM >>>
""Resource Table"" in system generation is an IDMS-DB concept - it is
used
when in a front-end to back-end scenario whereby a front-end IDMS-DC
task accesses a back-end physical database. The front-end user tailors
his/her session to a DBNAME that points to a Resource Table entry that
tells front-end DBMS how to access back-end DBMC (eg. through SVC to
CV
Number etc). This has nothing to do with ENQ/DEQ Resource Names.

HTH - cheers - Gary

Ps - I have some history tucked away on the DC/UCF stuff - I'll try to
locate and post - in the meanwhile some ""general IDMS history"" is
available at http://oziua.shorturl.com

Outcomes