Replacement for the NCZ93205 subroutine.

[cedarlakebuzzards]

I have just uploaded a replacement for the NCZ93205 subroutine that
allows COBOL programs to access PDS members dynamically. The file is
PDSUNLOD.ZIP

This new routine is called PDSGET. It allows individual random access
of member or sequential pass of the directory. It can be called by MVT
COBOL and PL/I(F) programs. A demo program to print the contents of an
entire PDS is included in the ZIP.

COBOL PROGRAMS should call as PDSGET or NCZ93206.
PL/1(F) programs should call PDSGETP.

The comments in the code and the demo program document how to use
PDSGET.

[halfmeg]

Post by cedarlakebuzzards
I have just uploaded a replacement for the NCZ93205 subroutine that
allows COBOL programs to access PDS members dynamically. The file is
PDSUNLOD.ZIP
This new routine is called PDSGET. It allows individual random
access of member or sequential pass of the directory. It can be
called by MVT COBOL and PL/I(F) programs. A demo program to print
the contents of an entire PDS is included in the ZIP.
COBOL PROGRAMS should call as PDSGET or NCZ93206.
PL/1(F) programs should call PDSGETP.
The comments in the code and the demo program document how to use
PDSGET.

I haven't looked at either of these, but how does this differ from:

2004 Feb 28 ncz93205 Added subroutine to enable COBOL program access to partitioned datasets

http://www.jaymoseley.com/hercules/miscpgms.htm#AccessPDSMembers

Phil

[cedarlakebuzzards]

The new version has two new functions added that allow sequential
reading of the PDS directory (to retrieve member name) from COBOL
programs. In addition, PL/1 (F) programs can call and access all of
the functions. The module was renamed to PDSGET with entry
points/aliases of NCZ93205 and PDSGETP. PL/I (F) restricts external
program names to 7 characters.

If you don't want to read the directory or call it from PL/I, this
module offers nothing new over the "old" NCZ93205.

Ed

Post by cedarlakebuzzards
I have just uploaded a replacement for the NCZ93205 subroutine that
allows COBOL programs to access PDS members dynamically. The file is
PDSUNLOD.ZIP
This new routine is called PDSGET. It allows individual random
access of member or sequential pass of the directory. It can be
called by MVT COBOL and PL/I(F) programs. A demo program to print
the contents of an entire PDS is included in the ZIP.
COBOL PROGRAMS should call as PDSGET or NCZ93206.
PL/1(F) programs should call PDSGETP.
The comments in the code and the demo program document how to use
PDSGET.

2004 Feb 28 ncz93205 Added subroutine to enable COBOL program

access to partitioned datasets

http://www.jaymoseley.com/hercules/miscpgms.htm#AccessPDSMembers
Phil

[halfmeg]

Post by cedarlakebuzzards
The new version has two new functions added that allow sequential
reading of the PDS directory (to retrieve member name) from COBOL
programs. In addition, PL/1 (F) programs can call and access all
of the functions. The module was renamed to PDSGET with entry
points/aliases of NCZ93205 and PDSGETP. PL/I (F) restricts external
program names to 7 characters.
If you don't want to read the directory or call it from PL/I, this
module offers nothing new over the "old" NCZ93205.
<snip>

Ok, I've looked over both and the original.

Original is on CBT Overflow tape file #12 as u87003as.
Jay Moseley made modifications and posted on his site in 2004.
You modified Jay's version ( dropped *JLM* from his changes in open but left *JLM* in place for the +40 change IIRC ).

Along the way you used GETDIR from CBT Tape file #183 and found;
".GEN AIF (D,GETDIR).MEND " 'D' not supported in IFOX00.

Jay's install puts the module in SYS2.LINKLIB. Since it isn't in the TK3UPD system it seems to have never made it into TK3 at all. Both versions use different inline macros which is fine for standalone installs, but what happens when what should be a common macro changes. You would have a need to update each source deck which uses the macro inline to the new level. I haven't checked whether GETDIR is in a MACLIB on TK3.

So, all that to pose a few of questions.

What would you suggest is the best method to annotate the source as to where it came from and who made changes ?

The AMENDMENT HISTORY section only shows the original entry from 1982.

Could the change to GETDIR, which comes from Gilbert Saint-flour's CBT file # 183, be modified so that it works as originally written and only uses the IFOX00 amendment if IFOX00 is being used?

If so, it would eliminate the need for maintaining a separate version for IFOX00.

IIRC inline MACROs override the same named MACRO in a MACLIB. Would a temp MACLIB with the inline MACROs moved to it be beneficial for assembly/compilation on various levels of systems ?

Phil - bear with me folks - part of this exercise was to re-acquaint myself with this stuff after letting it go for a while

[cedarlakebuzzards]

Oh No - Busted by the IT auditor.

I did not think any one would be interested in such detailed change
control/audit trail information.

Ed

Post by halfmeg

Post by cedarlakebuzzards
The new version has two new functions added that allow sequential
reading of the PDS directory (to retrieve member name) from COBOL
programs. In addition, PL/1 (F) programs can call and access all
of the functions. The module was renamed to PDSGET with entry
points/aliases of NCZ93205 and PDSGETP. PL/I (F) restricts external
program names to 7 characters.
If you don't want to read the directory or call it from PL/I, this
module offers nothing new over the "old" NCZ93205.
<snip>

Ok, I've looked over both and the original.
Original is on CBT Overflow tape file #12 as u87003as.
Jay Moseley made modifications and posted on his site in 2004.
You modified Jay's version ( dropped *JLM* from his changes in open

but left *JLM* in place for the +40 change IIRC ).

Post by halfmeg
Along the way you used GETDIR from CBT Tape file #183 and found;
".GEN AIF (D,GETDIR).MEND " 'D' not supported in IFOX00.
Jay's install puts the module in SYS2.LINKLIB. Since it isn't in the

TK3UPD system it seems to have never made it into TK3 at all. Both
versions use different inline macros which is fine for standalone
installs, but what happens when what should be a common macro changes.
You would have a need to update each source deck which uses the macro
inline to the new level. I haven't checked whether GETDIR is in a
MACLIB on TK3.

Post by halfmeg
So, all that to pose a few of questions.
What would you suggest is the best method to annotate the source as to

where it came from and who made changes ?

Post by halfmeg
The AMENDMENT HISTORY section only shows the original entry from 1982.
Could the change to GETDIR, which comes from Gilbert Saint-flour's CBT

file # 183, be modified so that it works as originally written and only
uses the IFOX00 amendment if IFOX00 is being used?

Post by halfmeg
If so, it would eliminate the need for maintaining a separate version for IFOX00.
IIRC inline MACROs override the same named MACRO in a MACLIB. Would a

temp MACLIB with the inline MACROs moved to it be beneficial for
assembly/compilation on various levels of systems ?

Post by halfmeg
Phil - bear with me folks - part of this exercise was to re-acquaint

myself with this stuff after letting it go for a while

[halfmeg]

Post by cedarlakebuzzards
Oh No - Busted by the IT auditor.
I did not think any one would be interested in such detailed change
control/audit trail information.
<snip>

Yes, we have your code in lockup. Would you like to have the Public Defender visit? Bail hasn't been set yet but we understand that there are numerous bonding agencies available to release your code until final disposition. :-)

The primary reason I 'audited' your contribution is that I have finally gotten some breathing room to restart the TK3 Update work. I released a pre-Beta version to several developers and some testers back late last year. Bug reports came back and a list of modifications needed was saved on a disk which currently only exists as a Ghost Image of the drive.

I had hoped to update the Host software to XP from Win2K by having 2 partitions and just running the restored Beta environment out of the non-Host OS partition. The initial try didn't work out so well and I am rethinking what to do for that situation ( currently disk has been zeroed out ).

Finally we get to the why proper. There have been numerous modifications to TK3 which normally occur in one of two methods, under SMP control ( like usermods ) and outside of SMP control ( like RPF ).

When we distributed TK3SU1, it was pretty much a rush thing and I had set an artificial deadline to make it available. USERMOD changes consisted of rejecting prior mods and submitting a reworked item. Some new, never before in TK, were added and several independent installs were performed, such as RPF and JRP.

In the pre-BETA I elected to trim or not store the USERMODs on DASD. An example of trimming is JRP where all the source except for the module where password changes are made and JCL to relink after password customization were deleted to conserve space. The SMP USERMODS were submitted from the card reader and never uploaded to be saved on DASD.

The net result of my attempt to reduce the size of TK3 Update was pretty successful. By dropping the MVS and CBT source packs and doing some extra-ordinary work, the size of TK3 Update wound up being less than 70 MB zipped. That isn't a shadow update or non-SMP environment, it's a standalone MVS environment with many things the original TK3 and TK3SU1 didn't have.

Since there are multiple versions of some USERMODS now running on various levels of TK3, my 'audit' was intended to help me in figuring out how to maintain a history if not the actual sources along the way for the various modifications. Perhaps that isn't a valid concern, but like I stated it has been awhile since I touched any of this and getting my feet wet again has to start somewhere.

Phil - didn't mean to pick on your contribution personally

[cedarlakebuzzards]

Phil

Thanks for the explaination. I never thought you were picking on my
contribution but I did wonder why the detailed audit trail interest.
Knowing what you are attempting to accomplish, I understand why the
interest in the details.

Ed

Post by halfmeg

Post by cedarlakebuzzards
Oh No - Busted by the IT auditor.
I did not think any one would be interested in such detailed change
control/audit trail information.
<snip>

Yes, we have your code in lockup. Would you like to have the Public

Defender visit? Bail hasn't been set yet but we understand that there
are numerous bonding agencies available to release your code until final
disposition. :-)

Post by halfmeg
The primary reason I 'audited' your contribution is that I have

finally gotten some breathing room to restart the TK3 Update work. I
released a pre-Beta version to several developers and some testers back
late last year. Bug reports came back and a list of modifications
needed was saved on a disk which currently only exists as a Ghost Image
of the drive.

Post by halfmeg
I had hoped to update the Host software to XP from Win2K by having 2

partitions and just running the restored Beta environment out of the
non-Host OS partition. The initial try didn't work out so well and I am
rethinking what to do for that situation ( currently disk has been
zeroed out ).

Post by halfmeg
Finally we get to the why proper. There have been numerous

modifications to TK3 which normally occur in one of two methods, under
SMP control ( like usermods ) and outside of SMP control ( like RPF ).

Post by halfmeg
When we distributed TK3SU1, it was pretty much a rush thing and I had

set an artificial deadline to make it available. USERMOD changes
consisted of rejecting prior mods and submitting a reworked item. Some
new, never before in TK, were added and several independent installs
were performed, such as RPF and JRP.

Post by halfmeg
In the pre-BETA I elected to trim or not store the USERMODs on DASD.

An example of trimming is JRP where all the source except for the module
where password changes are made and JCL to relink after password
customization were deleted to conserve space. The SMP USERMODS were
submitted from the card reader and never uploaded to be saved on DASD.

Post by halfmeg
The net result of my attempt to reduce the size of TK3 Update was

pretty successful. By dropping the MVS and CBT source packs and doing
some extra-ordinary work, the size of TK3 Update wound up being less
than 70 MB zipped. That isn't a shadow update or non-SMP environment,
it's a standalone MVS environment with many things the original TK3 and
TK3SU1 didn't have.

Post by halfmeg
Since there are multiple versions of some USERMODS now running on

various levels of TK3, my 'audit' was intended to help me in figuring
out how to maintain a history if not the actual sources along the way
for the various modifications. Perhaps that isn't a valid concern, but
like I stated it has been awhile since I touched any of this and getting
my feet wet again has to start somewhere.

Post by halfmeg
Phil - didn't mean to pick on your contribution personally

[cedarlakebuzzards]

Post by halfmeg

Post by cedarlakebuzzards
Oh No - Busted by the IT auditor.
<snip>

Yes, we have your code in lockup. Would you like to have the Public Defender visit? Bail hasn't been set yet but we understand that there are numerous bonding agencies available to release your code until final disposition. :-)
<snip>

Thanks for the offer but I am represented by law firm Dewey, Cheetham and Howe. The associate handling my case is I. Fleecem. :=)

Hmmmm. Maybe I should take the Public Defender.....