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

Discussion created by ca.portal.admin on Mar 22, 2007
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
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