halfmeg | 1 Apr 05:01 2010
Picon

Re: Replacement for the NCZ93205 subroutine.

 



> cedarlakebuzzards wrote:

> 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

__._,_.___
Recent Activity:
.

__,_._,___
cedarlakebuzzards | 1 Apr 08:33 2010
Picon

Re: Replacement for the NCZ93205 subroutine.

 

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

--- In turnkey-mvs <at> yahoogroups.com, "halfmeg" <opplr <at> ...> wrote:
>
>
>
> > cedarlakebuzzards wrote:
>
> > 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
>

__._,_.___
Recent Activity:
.

__,_._,___
halfmeg | 2 Apr 16:15 2010
Picon

Re: Replacement for the NCZ93205 subroutine.

 

> cedarlakebuzzards wrote:

> 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

__._,_.___
Recent Activity:
.

__,_._,___
cedarlakebuzzards | 4 Apr 08:24 2010
Picon

Re: Replacement for the NCZ93205 subroutine.

 

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
--- In turnkey-mvs <at> yahoogroups.com, "halfmeg" <opplr <at> ...> wrote:
>
> > cedarlakebuzzards wrote:
>
> > 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
>

__._,_.___
Recent Activity:
.

__,_._,___
halfmeg | 4 Apr 11:51 2010
Picon

Re: Replacement for the NCZ93205 subroutine.

 

> cedarlakebuzzards wrote:

> 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

__._,_.___
Recent Activity:
.

__,_._,___
cedarlakebuzzards | 5 Apr 07:22 2010
Picon

Re: Replacement for the NCZ93205 subroutine.

 

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

--- In turnkey-mvs <at> yahoogroups.com, "halfmeg" <opplr <at> ...> wrote:
>
> > cedarlakebuzzards wrote:
>
> > 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
>

__._,_.___
Recent Activity:
.

__,_._,___
cedarlakebuzzards | 6 Apr 06:52 2010
Picon

Re: Replacement for the NCZ93205 subroutine.

 



--- In turnkey-mvs <at> yahoogroups.com, "halfmeg" <opplr <at> ...> wrote:
>
> > cedarlakebuzzards wrote:
>
> > 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.....

__._,_.___
Recent Activity:
.

__,_._,___
RonH | 17 Apr 21:28 2010
Picon

Basic Maintenance for a noob.

 

Hi, My name is Ron and I am a noob.

I am assuming that these machines don't run without certain
maintenance tasks performed at regular intervals..
Backups, 'Printing' built up MF/1 reports

For example on the console today I see a message:
$HASP050 RESOURCE SHORTAGE CODE=JQES

also some of my printers are 'halted' according to
$DU is that bad?

Thanks.

Ron the noob

__._,_.___
Recent Activity:
.

__,_._,___
scott | 17 Apr 21:40 2010
Picon
Picon

Re: Basic Maintenance for a noob.

 

Hello Ron,

By maintenance, it depends what you have or is setup. In the case of
MF/1, it does generate output which can fill up spool as you are
probably seeing. Shut it down by issuing the command "P MF1" (which
should work for you).
Backups can be done, and probably the best, outside of the OS by
using what you got with Linux or Windows.
The JES2 spool has various queues and the JQE (Job Queue Element) is
one such. You can either print what you have in spool or purge it.
The halting of the printer means, under Hercules, that a printer is
not setup properly or it has not been directed to a host file on Windows
or Linux.

Scott

On 04/17/2010 03:28 PM, RonH wrote:
> Hi, My name is Ron and I am a noob.
>
> I am assuming that these machines don't run without certain
> maintenance tasks performed at regular intervals..
> Backups, 'Printing' built up MF/1 reports
>
> For example on the console today I see a message:
> $HASP050 RESOURCE SHORTAGE CODE=JQES
>
> also some of my printers are 'halted' according to
> $DU is that bad?
>
> Thanks.
>
> Ron the noob
>
>

__._,_.___
Recent Activity:
.

__,_._,___
Ron Hudson | 17 Apr 21:51 2010
Picon

Re: Basic Maintenance for a noob.

 


Thanks for the helpful reply Scott.

I would like to run this as much like a real production machine as I can,
for experience sake, I found something that said to

$Sprinter1
$Sprinter2

Will I have to do that at each ipl?


And when I did that a stream of pent up printing jobs went to the printers
(And then to host system files I hope)

Is MF/1 used in production? would my "boss" expect to see it?

Thanks again
Ron the -slightly- less noobish


On Sat, Apr 17, 2010 at 12:40 PM, scott <svetter <at> ameritech.net> wrote:
 

Hello Ron,

By maintenance, it depends what you have or is setup. In the case of
MF/1, it does generate output which can fill up spool as you are
probably seeing. Shut it down by issuing the command "P MF1" (which
should work for you).
Backups can be done, and probably the best, outside of the OS by
using what you got with Linux or Windows.
The JES2 spool has various queues and the JQE (Job Queue Element) is
one such. You can either print what you have in spool or purge it.
The halting of the printer means, under Hercules, that a printer is
not setup properly or it has not been directed to a host file on Windows
or Linux.

Scott



__._,_.___
Recent Activity:
.

__,_._,___

Gmane