ca.portal.admin

Re:Re: Release 17.0 LTE control block change

Discussion created by ca.portal.admin on Nov 12, 2009
Thanks for heads up

DSECT changes also occurred going from R15 to R16, requiring a bunch of
re-assemblies. In some cases logic changes.

I don't think IDMS will ever relieve the need for a knowledgeable
assembler programmer as CICS has.

BR R14

Rob Klan/Cincinnati/IBM
Phone: 1-877-205-4871 (T/L: 349-2446)
VOIP Users 1-513-897-8148
ITN: 23492446
Email: rklan@us.ibm.com
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Release 17.0 LTE control block change
"Thanks for heads up

DSECT changes also occurred going from R15 to R16, requiring a bunch of
re-assemblies. In some cases logic changes.

I don't think IDMS will ever relieve the need for a knowledgeable
assembler programmer as CICS has.

BR R14

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



From:
""Cherlet, Gary (JTS)"" <Gary.Cherlet@SA.GOV.AU>
To:
IDMS-L@LISTSERV.IUASSN.COM
Date:
11/12/2009 07:48 AM
Subject:
Release 17.0 LTE control block change
Sent by:
IDMS Public Discussion Forum <IDMS-L@LISTSERV.IUASSN.COM>



Traditionally when we upgrade a major release of IDMS we run some DSECT
compares to see at what offset any changes have occurred in the DSECTs
that we reference in our IDMS-DC Assembler. If the first changes are
""further down"" than the data items that we reference we don't bother with
re-assembly of programs that reference the changed DSECTs. Of course if
the offset of a referenced data item has changed then we do the
re-assembly. Generally this results in very few, if any, programs that
need to be re-assembled and then managed during the installation process.

In the case of R17 there has been a change to the LTE - a commonly
referenced IDMS-DC control block in our assembler - that has impacted 40+
of our programs. Basically - the ""fixed portion"" of the LTE is now a FULL
WORD longer. This displaces a number of key items in the LTE that we
frequently reference by 4 bytes - below is a partial list of the (main)
items that have affected us:

LTEPTEA LTEUSRWA LTESONRC LTENXTSK LTEAUTSK

One other change that has affected us is the change to the Scratch Work
Area - it just impacts one program which likely only impact very few users
(if any - other than us). We have a program that we use at times, when
monitoring Scratch Usage closely, (DBUTPX26 in case we have ""shared"" it
with anybody out there) that looks at the Scratch Work (SCRW) area bit map
for pages in use flags - and ""draws"" a display that is mapped out for the
benefit of those who are interested in Scratch usage. Prior to release
17.0 there was just the one SCRW followed by a single bit map. While there
is still only one SCRW - there can be multiple Scratch allocations - this
is handled by allocating a SCRW Extension (SCRWX) for the first, and then
each subsequent (dynamically acquired) Scratch area. There is a ""bit map""
for each SCRWX. In case anybody uses our version of this program be aware
that the code in DBUTPX26 had to be changed to allow for this new control
block structure. We have made the simple change of creating the usage map
for the first Scratch allocation, at the moment there is no effort to
follow the ""next pointer"" in the chain of secondary scratch allocations to
also create bit maps for those allocations.

Cheers - Gary

Gary Cherlet
Justice Technology Services
Department of Justice, SA Government

"""""""" Telephone +61 (0)8 8226 5199
@@ Facsimile +61 (0)8 8226 5311
> Mobile +61 (0)41 333 1613
\/ MailTo:gary.cherlet@sa.gov.au

Murphy says:
1. ""Everything is a system.""
2. ""Everything is part of a larger system.""
3. ""The universe is infinitely systematized both upward (larger systems)
and downward (smaller systems).""
4. ""All systems are infinitely complex (the illusion of simplicity comes
from focusing attention on one or a few variables).""

This e-mail message and any attachments are qualified as follows:
Addressing: If you have received this e-mail in error, please advise by
reply e-mail to the sender. Please also destroy the original transmission
and its contents. Confidentiality: This e-mail may contain confidential
information which also may be legally privileged. Only the intended
recipient(s) may access, use, distribute or copy this e-mail. Individual
Views: Unless otherwise indicated, the views expressed are those of the
sender, not Justice Technology Services. Computer Viruses: It is the
recipient's responsibility to check the e-mail and any attached files for
viruses.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Release 17.0 LTE control block change
"Thanks for heads up

DSECT changes also occurred going from R15 to R16, requiring a bunch of
re-assemblies. In some cases logic changes.

I don't think IDMS will ever relieve the need for a knowledgeable
assembler programmer as CICS has.

BR R14

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



From:
""Cherlet, Gary (JTS)"" <Gary.Cherlet@SA.GOV.AU>
To:
IDMS-L@LISTSERV.IUASSN.COM
Date:
11/12/2009 07:48 AM
Subject:
Release 17.0 LTE control block change
Sent by:
IDMS Public Discussion Forum <IDMS-L@LISTSERV.IUASSN.COM>



Traditionally when we upgrade a major release of IDMS we run some DSECT
compares to see at what offset any changes have occurred in the DSECTs
that we reference in our IDMS-DC Assembler. If the first changes are
""further down"" than the data items that we reference we don't bother with
re-assembly of programs that reference the changed DSECTs. Of course if
the offset of a referenced data item has changed then we do the
re-assembly. Generally this results in very few, if any, programs that
need to be re-assembled and then managed during the installation process.

In the case of R17 there has been a change to the LTE - a commonly
referenced IDMS-DC control block in our assembler - that has impacted 40+
of our programs. Basically - the ""fixed portion"" of the LTE is now a FULL
WORD longer. This displaces a number of key items in the LTE that we
frequently reference by 4 bytes - below is a partial list of the (main)
items that have affected us:

LTEPTEA LTEUSRWA LTESONRC LTENXTSK LTEAUTSK

One other change that has affected us is the change to the Scratch Work
Area - it just impacts one program which likely only impact very few users
(if any - other than us). We have a program that we use at times, when
monitoring Scratch Usage closely, (DBUTPX26 in case we have ""shared"" it
with anybody out there) that looks at the Scratch Work (SCRW) area bit map
for pages in use flags - and ""draws"" a display that is mapped out for the
benefit of those who are interested in Scratch usage. Prior to release
17.0 there was just the one SCRW followed by a single bit map. While there
is still only one SCRW - there can be multiple Scratch allocations - this
is handled by allocating a SCRW Extension (SCRWX) for the first, and then
each subsequent (dynamically acquired) Scratch area. There is a ""bit map""
for each SCRWX. In case anybody uses our version of this program be aware
that the code in DBUTPX26 had to be changed to allow for this new control
block structure. We have made the simple change of creating the usage map
for the first Scratch allocation, at the moment there is no effort to
follow the ""next pointer"" in the chain of secondary scratch allocations to
also create bit maps for those allocations.

Cheers - Gary

Gary Cherlet
Justice Technology Services
Department of Justice, SA Government

"""""""" Telephone +61 (0)8 8226 5199
@@ Facsimile +61 (0)8 8226 5311
> Mobile +61 (0)41 333 1613
\/ MailTo:gary.cherlet@sa.gov.au

Murphy says:
1. ""Everything is a system.""
2. ""Everything is part of a larger system.""
3. ""The universe is infinitely systematized both upward (larger systems)
and downward (smaller systems).""
4. ""All systems are infinitely complex (the illusion of simplicity comes
from focusing attention on one or a few variables).""

This e-mail message and any attachments are qualified as follows:
Addressing: If you have received this e-mail in error, please advise by
reply e-mail to the sender. Please also destroy the original transmission
and its contents. Confidentiality: This e-mail may contain confidential
information which also may be legally privileged. Only the intended
recipient(s) may access, use, distribute or copy this e-mail. Individual
Views: Unless otherwise indicated, the views expressed are those of the
sender, not Justice Technology Services. Computer Viruses: It is the
recipient's responsibility to check the e-mail and any attached files for
viruses.
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Release 17.0 LTE control block change
"Traditionally when we upgrade a major release of IDMS we run some DSECT compares to see at what offset any changes have occurred in the DSECTs that we reference in our IDMS-DC Assembler. If the first changes are ""further down"" than the data items that we reference we don't bother with re-assembly of programs that reference the changed DSECTs. Of course if the offset of a referenced data item has changed then we do the re-assembly. Generally this results in very few, if any, programs that need to be re-assembled and then managed during the installation process.

In the case of R17 there has been a change to the LTE - a commonly referenced IDMS-DC control block in our assembler - that has impacted 40+ of our programs. Basically - the ""fixed portion"" of the LTE is now a FULL WORD longer. This displaces a number of key items in the LTE that we frequently reference by 4 bytes - below is a partial list of the (main) items that have affected us:

LTEPTEA LTEUSRWA LTESONRC LTENXTSK LTEAUTSK

One other change that has affected us is the change to the Scratch Work Area - it just impacts one program which likely only impact very few users (if any - other than us). We have a program that we use at times, when monitoring Scratch Usage closely, (DBUTPX26 in case we have ""shared"" it with anybody out there) that looks at the Scratch Work (SCRW) area bit map for pages in use flags - and ""draws"" a display that is mapped out for the benefit of those who are interested in Scratch usage. Prior to release 17.0 there was just the one SCRW followed by a single bit map. While there is still only one SCRW - there can be multiple Scratch allocations - this is handled by allocating a SCRW Extension (SCRWX) for the first, and then each subsequent (dynamically acquired) Scratch area. There is a ""bit map"" for each SCRWX. In case anybody uses our version of this program be aware that the code in DBUTPX26 had to be changed to allow for this new control block structure. We have made the simple change of creating the usage map for the first Scratch allocation, at the moment there is no effort to follow the ""next pointer"" in the chain of secondary scratch allocations to also create bit maps for those allocations.

Cheers - Gary

Gary Cherlet
Justice Technology Services
Department of Justice, SA Government

"""""""" Telephone +61 (0)8 8226 5199
@@ Facsimile +61 (0)8 8226 5311
> Mobile +61 (0)41 333 1613
\/ MailTo:gary.cherlet@sa.gov.au

Murphy says:
1. ""Everything is a system.""
2. ""Everything is part of a larger system.""
3. ""The universe is infinitely systematized both upward (larger systems) and downward (smaller systems).""
4. ""All systems are infinitely complex (the illusion of simplicity comes from focusing attention on one or a few variables).""

This e-mail message and any attachments are qualified as follows: Addressing: If you have received this e-mail in error, please advise by reply e-mail to the sender. Please also destroy the original transmission and its contents. Confidentiality: This e-mail may contain confidential information which also may be legally privileged. Only the intended recipient(s) may access, use, distribute or copy this e-mail. Individual Views: Unless otherwise indicated, the views expressed are those of the sender, not Justice Technology Services. Computer Viruses: It is the recipient's responsibility to check the e-mail and any attached files for viruses.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Release 17.0 LTE control block change
"Traditionally when we upgrade a major release of IDMS we run some DSECT com=
pares to see at what offset any changes have occurred in the DSECTs that we=
reference in our IDMS-DC Assembler. If the first changes are ""further down=
"" than the data items that we reference we don't bother with re-assembly of=
programs that reference the changed DSECTs. Of course if the offset of a r=
eferenced data item has changed then we do the re-assembly. Generally this =
results in very few, if any, programs that need to be re-assembled and then=
managed during the installation process.

In the case of R17 there has been a change to the LTE - a commonly referenc=
ed IDMS-DC control block in our assembler - that has impacted 40+ of our pr=
ograms. Basically - the ""fixed portion"" of the LTE is now a FULL WORD longe=
r. This displaces a number of key items in the LTE that we frequently refer=
ence by 4 bytes - below is a partial list of the (main) items that have aff=
ected us:

LTEPTEA LTEUSRWA LTESONRC LTENXTSK LTEAUTSK

One other change that has affected us is the change to the Scratch Work Are=
a - it just impacts one program which likely only impact very few users (if=
any - other than us). We have a program that we use at times, when monitor=
ing Scratch Usage closely, (DBUTPX26 in case we have ""shared"" it with anybo=
dy out there) that looks at the Scratch Work (SCRW) area bit map for pages =
in use flags - and ""draws"" a display that is mapped out for the benefit of =
those who are interested in Scratch usage. Prior to release 17.0 there was =
just the one SCRW followed by a single bit map. While there is still only o=
ne SCRW - there can be multiple Scratch allocations - this is handled by al=
locating a SCRW Extension (SCRWX) for the first, and then each subsequent (=
dynamically acquired) Scratch area. There is a ""bit map"" for each SCRWX. In=
case anybody uses our version of this program be aware that the code in DB=
UTPX26 had to be changed to allow for this new control block structure. We =
have made the simple change of creating the usage map for the first Scratch=
allocation, at the moment there is no effort to follow the ""next pointer"" =
in the chain of secondary scratch allocations to also create bit maps for t=
hose allocations.

Cheers - Gary=20

Gary Cherlet
Justice Technology Services
Department of Justice, SA Government

"""""""" Telephone +61 (0)8 8226 5199
@@ Facsimile +61 (0)8 8226 5311
> Mobile +61 (0)41 333 1613
\/ MailTo:gary.cherlet@sa.gov.au

Murphy says:
1. ""Everything is a system.""
2. ""Everything is part of a larger system.""
3. ""The universe is infinitely systematized both upward (larger systems) an=
d downward (smaller systems).""
4. ""All systems are infinitely complex (the illusion of simplicity comes fr=
om focusing attention on one or a few variables).""

This e-mail message and any attachments are qualified as follows: Addressin=
g: If you have received this e-mail in error, please advise by reply e-mai=
l to the sender. Please also destroy the original transmission and its con=
tents. Confidentiality: This e-mail may contain confidential information w=
hich also may be legally privileged. Only the intended recipient(s) may ac=
cess, use, distribute or copy this e-mail. Individual Views: Unless otherw=
ise indicated, the views expressed are those of the sender, not Justice Tec=
hnology Services. Computer Viruses: It is the recipient's responsibility t=
o check the e-mail and any attached files for viruses.
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: COPY MODULE in a COBOL program
"It will pull in the COBOL version.
Be aware that if you have multiple versions (version is 1, version is 2),
it will pull in the highest version, that is in the manual, however, it
does not explicitly say it will look for a language specific version first.

So it will look for language, then mode, then highest version

For a program with a mode of DC-BATCH
If you have the following modules:
module xxxxxxxx version 1 lang cobol
module xxxxxxxx version 2
module xxxxxxxx version 3
module xxxxxxxx version 3 lang cobol
module xxxxxxxx version 4
It will pick module xxxxxxxx version 3 lang cobol

If you have modules:
module xxxxxxxx version 1 lang cobol
module xxxxxxxx version 2 mode dc-batch
module xxxxxxxx version 3
module xxxxxxxx version 3 lang cobol
module xxxxxxxx version 4
It will pick module xxxxxxxx version 3 lang cobol

If you have module:
module xxxxxxxx version 1 lang cobol mode dc-batch
module xxxxxxxx version 2 mode dc-batch
module xxxxxxxx version 3
module xxxxxxxx version 3 lang cobol
module xxxxxxxx version 4
It will pick It will pick module xxxxxxxx version 1 lang cobol mode
dc-batch

If you have module:
module xxxxxxxx version 3
module xxxxxxxx version 4
It will pick It will pick module xxxxxxxx version 4



Tommy Petersen
110 Cokesbury Rd
Room 542H
Lebanon, NJ 08833

Phone:
Internal 200 - 3699
External (908) 236-3699
Fax: (908) 236-3692




Buz Williams
<buz.williams@GMA
IL.COM> To
Sent by: IDMS IDMS-L@LISTSERV.IUASSN.COM
Public Discussion cc
Forum
<IDMS-L@LISTSERV. Subject
IUASSN.COM> COPY MODULE in a COBOL program


11/11/2009 05:37
PM


Please respond to
buzwilliams@gmail
.com






Does anyone know how the COBOL pre-processor would behave in this case?

A COBOL program has in it:
COPY IDMS xxxxxxxx.

In the IDD there are 2 modules named xxxxxxx. One has LANGUAGE IS COBOL on
it, the other does not.

Which one will get pulled into the COBOL program?

Buz
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: COPY MODULE in a COBOL program
"It will pull in the COBOL version.
Be aware that if you have multiple versions (version is 1, version is 2),
it will pull in the highest version, that is in the manual, however, it
does not explicitly say it will look for a language specific version first.

So it will look for language, then mode, then highest version

For a program with a mode of DC-BATCH
If you have the following modules:
module xxxxxxxx version 1 lang cobol
module xxxxxxxx version 2
module xxxxxxxx version 3
module xxxxxxxx version 3 lang cobol
module xxxxxxxx version 4
It will pick module xxxxxxxx version 3 lang cobol

If you have modules:
module xxxxxxxx version 1 lang cobol
module xxxxxxxx version 2 mode dc-batch
module xxxxxxxx version 3
module xxxxxxxx version 3 lang cobol
module xxxxxxxx version 4
It will pick module xxxxxxxx version 3 lang cobol

If you have module:
module xxxxxxxx version 1 lang cobol mode dc-batch
module xxxxxxxx version 2 mode dc-batch
module xxxxxxxx version 3
module xxxxxxxx version 3 lang cobol
module xxxxxxxx version 4
It will pick It will pick module xxxxxxxx version 1 lang cobol mode
dc-batch

If you have module:
module xxxxxxxx version 3
module xxxxxxxx version 4
It will pick It will pick module xxxxxxxx version 4



Tommy Petersen
110 Cokesbury Rd
Room 542H
Lebanon, NJ 08833

Phone:
Internal 200 - 3699
External (908) 236-3699
Fax: (908) 236-3692




Buz Williams
<buz.williams@GMA
IL.COM> To
Sent by: IDMS IDMS-L@LISTSERV.IUASSN.COM
Public Discussion cc
Forum
<IDMS-L@LISTSERV. Subject
IUASSN.COM> COPY MODULE in a COBOL program


11/11/2009 05:37
PM


Please respond to
buzwilliams@gmail
.com






Does anyone know how the COBOL pre-processor would behave in this case?

A COBOL program has in it:
COPY IDMS xxxxxxxx.

In the IDD there are 2 modules named xxxxxxx. One has LANGUAGE IS COBOL on
it, the other does not.

Which one will get pulled into the COBOL program?

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








Normal

Normal
batch JCL FTP changes to support.ca.com
"it looks like CA has changed a few things (i found out the hard way when
trying to send a dump Sunday)
my old JCL would not work - after some research i discovered the
following:



1) there is no longer a separate tab for creating an FTP directory - it is
now under the FILE ATTACHMENTS tab
2) the FTP server name is now SUPPORTFTP.CA.COM
3) the FTP now requires support ID/support password, no longer
anonymous/support ID to get into the system
4) the directory you FTP to now appears to be:

site-id/case-number/files_from_customer


admittedly, it took me only 5 minutes to find these changes, but if this
saves you any time when you next try to FTP to CA, then mission
accomplished!

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

you only need to test the programs that you want to work correctly




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
batch JCL FTP changes to support.ca.com
"it looks like CA has changed a few things (i found out the hard way when
trying to send a dump Sunday)
my old JCL would not work - after some research i discovered the
following:



1) there is no longer a separate tab for creating an FTP directory - it is
now under the FILE ATTACHMENTS tab
2) the FTP server name is now SUPPORTFTP.CA.COM
3) the FTP now requires support ID/support password, no longer
anonymous/support ID to get into the system
4) the directory you FTP to now appears to be:

site-id/case-number/files_from_customer


admittedly, it took me only 5 minutes to find these changes, but if this
saves you any time when you next try to FTP to CA, then mission
accomplished!

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

you only need to test the programs that you want to work correctly




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 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: batch JCL FTP changes to support.ca.com
"Chris,

Are the support ID and password (item #3) the same ones that you log in wit=
h online?

Outcomes