ca.portal.admin

Re: latest from CA

Discussion created by ca.portal.admin on Oct 2, 2006
What CA has mentioned in today's webcast is that they expect R17 to be
GA in
Q2 2008.
Therefore (since they are usually merciful, and give a one year advance
notice) support for R15 will probably be dropped a year after R17
becomes
GA, hence not before Q2 2009.

Rafi Gefen
IDMS DBA & Senior System Analyst
IT Division, BEZEQ The Israel Telecom. Corp. Ltd.
Office: +972-3-576-3758
Mobile: +972-54-576-7234
Rafige@Gmail.com,Rafige@Bezeq.com



On 10/2/06, Chris Hoelscher <choelscher@humana.com> wrote:
>
just thought I would pass along ..

the tentative provisional projected non-official sunset date
for
release 15 is Q2 2008 - to coincide with the release of release 17
(which
has a lot of great features)


Chris Hoelscher
IDMS & DB2 Database Administrator
Humana Inc
502-476-2538
choelscher@humana.com




The information transmitted is intended only for the person or entity
to
which it is addressed and may contain CONFIDENTIAL material. If you
receive
this material/information in error, please contact the sender and
delete or
destroy the material/information.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
TCP/IP question - HTTPS
"I have been testing the new TCP/IP sockets API for IDMS. For now, we
are limiting this to calls out. So far, I can successfully connect to
both internal and external sites, and can retrieve information from
non-SSL sites. But when I send requests to SSL sites (""https"" if you
were doing it from a web browser), I get the following response:
""You're speaking plain HTTP to an SSL-enabled server port. Instead use
the HTTPS scheme to access this URL, please.""

What do I need to do to ""speak HTTPS"", other than specify port 443?

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
APPC ALLOCATE / APPCCODE / APPCERC
"I have a couple of questions for any of you APPC LU6.2 experts out there.

We have been having some problems lately with LU6.2 between IDMS and a STRATUS machine. After making some changes to some dialogs in TEST and re-testing, some interesting things are surfacing.

1. On the ALLOCATE statement where the IDMS dialog initiates the transaction, the ALLOCATE is coming back as successful even though the service in STRATUS is not available. Here is the ALLOCATE statemSent:
ALLOCATE LU-NAME 'LTSPSB13' MODE-NAME 'SNAAPPC'
TPN 'PDCHR2' SYNC-LEVEL CONFIRM NOFORMAT.
What I am saying is that 'PDCHR2' is not running on STRATUS, yet the ALLOCATE comes back as successful. It isn't until the CONFIRM after our first SEND-DATA that we finally fail. Why doesn't the application fail on the initial ALLOCATE if 'PDCHR2' is not available?

2. When is it appropriate to test APPCCODE for a value less than zero? We have tested with AUTOSTATUS ON and OFF and get the same results. There are many instances where the dialog aborts before it is given a chance to execute any error-checking logic to test the contents of this field. So now I'm wondering: What is the value of coding for this if most of the time the dialogs abort before the error-checking can even be done?

I am ashamed to admit we are still running 14.0 on OS/390 (going to 16.0 was given thumbs down), in case that makes any difference.

Thank You.
Jon Gocher
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: APPC ALLOCATE / APPCCODE / APPCERC
"Back in early 90s had to connect two business apps with LU62. I recall
using a REDBOOK and two articles from Xephon to help me understand
LU62...here is one of them...you will have to search for other two....

http://www.xephon.com/arcinframe.php//n003a03


Rob Klan/Cincinnati/IBM
Phone: 1-877-205-4871 (T/L: 349-2446)
ITN: 23492446
Email: rklan@us.ibm.com



""Boyce, Bill (GE Money)"" <Bill.Boyce@GE.COM>
Sent by: IDMS Public Discussion Forum <IDMS-L@LISTSERV.IUASSN.COM>
10/03/2006 06:17 PM
Please respond to
IDMS Public Discussion Forum <IDMS-L@LISTSERV.IUASSN.COM>


To
IDMS-L@LISTSERV.IUASSN.COM
cc

Subject
Re: APPC ALLOCATE / APPCCODE / APPCERC






Jon,
What I understand from many years of working with LU6.2 (18+) is
that there are underlying efficiencies within the software. every command
is not flushed out into the network. The software attempts to be efficient
by buffering up the request until either the buffer (as defined in the
bind image RU size in the mode table) is full or by a change in direction
command such as a send/receive or confirm. Therefore, allocates are
buffered up, with at least the first part of a send, before the actual
send is transmitted. That is why you don't see allocate errors until the
attempt to send data is tried.
We have always used assembler 'black boxes' which the applications
call for lu6.2 so I don't have any experiences with using ADS to answer
your second question.
HTH,
Bill Boyce

William M. Boyce
GE Money-Americas
Sr. Systems Engineer
IDMS, Mainframe, and AS400 Technologies

T 203 944 6183
F 203 944 3509
C 203 650 7755
D *370-6183
E bill.boyce@ge.com
www.ge.com

6 Corporate Drive
7th Fl - 7101
Shelton, CT 06484-6206

Outcomes