Re: Difficulties with TCP/IP and data sets

#1951

IPL with the starter system.
Create a new name, copy the members over.  Rename old dataset.  Rename
new dataset.
IPL with normal system.

Show quoted text

On Sat, Dec 26, 2020 at 12:36 PM Pedro Pinheiro <prppedro@...> wrote:

Thank you, both of you.

It works well either way. What's more intriguing is that I didn't find it easily in the manuals and Redbooks.

Anyway, there's, now, a second issue. The dataset is accessible, although I can't really write anything to it because it reached its limits (who the heck tights a configuration data set that much during the generation?).

Now I know the most feasible way of doing that is just creating another dataset and moving the files over. But how am I supposed to do that with a system dataset, which is currently open by the system?

About what Rahim said: thank you, but it seems not to be the problem, at all...

On Sat, Dec 26, 2020 at 2:30 PM Rupert Reynolds <rupertreynolds@...> wrote:

Good point, but I prefer to leavw the prefix, and simply use apostrophes around dataset names that don't start with it.

sub d(myjob) is easier to type than
sub roopy.d.cntl(myjob)

Same with
ex d(myclist) compared with
ex roopy.d.clistl(myclist)

call d(myprog) and test d(myprpg) likewise :-)

Roops

On Sat., Dec. 26, 2020, 16:33 Joe Monk, <joemonk64@...> wrote:

TSO PROFILE NOPREFIX.

Then try to access  your dataset.

Joe

On Sat, Dec 26, 2020 at 10:27 AM Pedro Pinheiro <prppedro@...> wrote:

Hi, all

I have a rather dumb question, I recognize. But I've been struggling with it for the past day. There's a data set (CENTER.PARMLIB) in which TCPPROF member is contained. TSO MVSCUST opens this file for me. And I can also access it through DSLIST. Though I can't access it anywhere. Any other ISPF utilities just tells me either the “Data set is not cataloged” or (if I specify the volume) “Data set is not found”.

That's quite problematic because, on top of all that, system have been abending on me, crying 'bout lack of space in the dataset. But I can't edit CENTER.PARMLIB allocation because all the tools which seems to deal with that can't find the data set. Also, when using the “ALLOC” command, it infers the dataset is prefixed the current login, SYSPROG1.

So, is there any way out of this mess?

Thanks,
Att.,
-trp

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

Re: Working with ISAM Data Sets

#1950

开云体育

Standard practice for production batch files in all the shops I have ever worked was to initialize files (ISAM or VSAM included) with a header record with a binary-zeroes key value and a date and sometimes also a time as the data.

?

Random addition of data with any key value after that initial header load is then possible, though not the best practice if large amounts of additional records are needed.

?

At my first MVT shop (mid-1970’s), we found that loading large amounts of data to an existing (already loaded with other data) ISAM file was actually most efficiently done in DESCENDING key order, due to the way ISAM works internally.

?

HTH

?

Peter

?

Show quoted text

From: [email protected] <[email protected]> On Behalf Of Rupert Reynolds
Sent: Saturday, December 26, 2020 12:39 PM
To: [email protected]
Subject: Re: [H390-MVS] Working with ISAM Data Sets

?

Standard practice when I was involved was to use REPRO to copy dummy data into any new VSAM dataset, to initialise it.

?

I can't remember whether it was one record (with a low key, to be ignored or deleted later), or literally no input data at all.

?

I'd agree VSAM is usually the way to go, but it still needs initialising. Well, it did when I was using BLDVRP, GENCB, MODCB macros and the like :-)

?

Roops

?

On Sat., Dec. 26, 2020, 16:32 Joe Monk, <joemonk64@...> wrote:

Yeah ... DONT use ISAM. You will regret?it if you do so.
?
USE VSAM KSDS instead. Easier and less complicated. If you need some pointers let me know.
?
Joe
?
On Sat, Dec 26, 2020 at 9:59 AM Patrik Schindler <poc@...> wrote:
Hello,

"The records that comprise a newly created data set must be presented for writing in ascending order by key."

Source:

Does this mean that I need to at least write one record with some arbitrary key value, and later (DISP=MOD) can add more records which are not necessarily in order with the key value already in the first record?

I want to find some practical use for a batch workflow involving collection of data and generating reports of it in TK4-. I decided to postpone VSAM to later when I feel skilled enough to create interactive applications using KICKS.

Thanks!

--

Re: Working with ISAM Data Sets

#1949

High values is still required for various system datasets.

On Sat, Dec 26, 2020 at 11:38 AM Rupert Reynolds
<rupertreynolds@...> wrote:

Standard practice when I was involved was to use REPRO to copy dummy data into any new VSAM dataset, to initialise it.

I can't remember whether it was one record (with a low key, to be ignored or deleted later), or literally no input data at all.

I'd agree VSAM is usually the way to go, but it still needs initialising. Well, it did when I was using BLDVRP, GENCB, MODCB macros and the like :-)

Roops

On Sat., Dec. 26, 2020, 16:32 Joe Monk, <joemonk64@...> wrote:

Yeah ... DONT use ISAM. You will regret it if you do so.

USE VSAM KSDS instead. Easier and less complicated. If you need some pointers let me know.

Joe

On Sat, Dec 26, 2020 at 9:59 AM Patrik Schindler <poc@...> wrote:

Hello,

"The records that comprise a newly created data set must be presented for writing in ascending order by key."

Source: 

Does this mean that I need to at least write one record with some arbitrary key value, and later (DISP=MOD) can add more records which are not necessarily in order with the key value already in the first record?

I want to find some practical use for a batch workflow involving collection of data and generating reports of it in TK4-. I decided to postpone VSAM to later when I feel skilled enough to create interactive applications using KICKS.

Thanks!

:wq! PoC

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

Re: Difficulties with TCP/IP and data sets

#1948

Thank you, both of you.

It works well either way. What's more intriguing is that I didn't find it easily in the manuals and Redbooks.

Anyway, there's, now, a second issue. The dataset is accessible, although I can't really write anything to it because it reached its limits (who the heck tights a configuration data set that much during the generation?).

Now I know the most feasible way of doing that is just creating another dataset and moving the files over. But how am I supposed to do that with a system dataset, which is currently open by the system?

About what Rahim said: thank you, but it seems not to be the problem, at all...

Show quoted text

On Sat, Dec 26, 2020 at 2:30 PM Rupert Reynolds <rupertreynolds@...> wrote:

Good point, but I prefer to leavw the prefix, and simply use apostrophes around dataset names that don't start with it.

sub d(myjob) is easier to type than
sub roopy.d.cntl(myjob)

Same with?
ex d(myclist) compared with
ex roopy.d.clistl(myclist)

call d(myprog) and test d(myprpg) likewise :-)

Roops

On Sat., Dec. 26, 2020, 16:33 Joe Monk, <joemonk64@...> wrote:
TSO PROFILE NOPREFIX.

Then try to access ?your dataset.

Joe

On Sat, Dec 26, 2020 at 10:27 AM Pedro Pinheiro <prppedro@...> wrote:
Hi, all

I have a rather dumb question, I recognize. But I've been struggling with it for the past day. There's a data set (CENTER.PARMLIB) in which TCPPROF member is contained. TSO MVSCUST opens this file for me. And I can also access it through DSLIST. Though I can't access it anywhere. Any other ISPF utilities just tells me either the “Data set is not cataloged” or (if I specify the volume) “Data set is not found”.

That's quite problematic because, on top of all that, system have been abending on me, crying 'bout lack of space in the dataset. But I can't edit CENTER.PARMLIB allocation because all the tools which seems to deal with that can't find the data set. Also, when using the “ALLOC” command, it infers the dataset is prefixed the current login, SYSPROG1.

So, is there any way out of this mess?

Thanks,
Att.,
-trp

Re: Working with ISAM Data Sets

#1947

Standard practice when I was involved was to use REPRO to copy dummy data into any new VSAM dataset, to initialise it.

I can't remember whether it was one record (with a low key, to be ignored or deleted later), or literally no input data at all.

I'd agree VSAM is usually the way to go, but it still needs initialising. Well, it did when I was using BLDVRP, GENCB, MODCB macros and the like :-)

Roops

Show quoted text

On Sat., Dec. 26, 2020, 16:32 Joe Monk, <joemonk64@...> wrote:

Yeah ... DONT use ISAM. You will regret?it if you do so.

USE VSAM KSDS instead. Easier and less complicated. If you need some pointers let me know.

Joe

On Sat, Dec 26, 2020 at 9:59 AM Patrik Schindler <poc@...> wrote:
Hello,

"The records that comprise a newly created data set must be presented for writing in ascending order by key."

Source:

Does this mean that I need to at least write one record with some arbitrary key value, and later (DISP=MOD) can add more records which are not necessarily in order with the key value already in the first record?

I want to find some practical use for a batch workflow involving collection of data and generating reports of it in TK4-. I decided to postpone VSAM to later when I feel skilled enough to create interactive applications using KICKS.

Thanks!

:wq! PoC

Re: Difficulties with TCP/IP and data sets

#1946

Good point, but I prefer to leavw the prefix, and simply use apostrophes around dataset names that don't start with it.

sub d(myjob) is easier to type than

sub roopy.d.cntl(myjob)

Same with?

ex d(myclist) compared with

ex roopy.d.clistl(myclist)

call d(myprog) and test d(myprpg) likewise :-)

Roops

Show quoted text

On Sat., Dec. 26, 2020, 16:33 Joe Monk, <joemonk64@...> wrote:

TSO PROFILE NOPREFIX.

Then try to access ?your dataset.

Joe

On Sat, Dec 26, 2020 at 10:27 AM Pedro Pinheiro <prppedro@...> wrote:
Hi, all

I have a rather dumb question, I recognize. But I've been struggling with it for the past day. There's a data set (CENTER.PARMLIB) in which TCPPROF member is contained. TSO MVSCUST opens this file for me. And I can also access it through DSLIST. Though I can't access it anywhere. Any other ISPF utilities just tells me either the “Data set is not cataloged” or (if I specify the volume) “Data set is not found”.

That's quite problematic because, on top of all that, system have been abending on me, crying 'bout lack of space in the dataset. But I can't edit CENTER.PARMLIB allocation because all the tools which seems to deal with that can't find the data set. Also, when using the “ALLOC” command, it infers the dataset is prefixed the current login, SYSPROG1.

So, is there any way out of this mess?

Thanks,
Att.,
-trp

Re: Difficulties with TCP/IP and data sets

#1945

TCPIP is not active by default in Hercules.? The following may give you some clues about how to activate it.? 

The availability and flavor of the instruction is controlled by three elements:

1.? The compile time FEATURE_TCPIP_EXTENSION definition: To allow enabling of the TCPIP instruction, the featxxx.h header files corresponding to the relevant architectures (feat370.h, feat390.h, feat900.h) must contain the statement:
```
??????????????? #define? FEATURE_TCPIP_EXTENSION
```
As shipped, SDL Hyperion 4.2 has this feature defined _only_ for the S/370 architecture (feat370.h).

2.? By default, the TCPIP instruction is disabled at run time, regardless of whether the compile time FEATURE_TCPIP_EXTENSION was defined or not.? If FEATURE_TCPIP_EXTENSION was defined for the architecture currently being used, the supervisor state flavor of the TCPIP instruction can only be enabled by issuing the command:
```
??????????????? facility enable HERC_TCPIP_EXTENSION
```
before IPLing the guest operating system.


3.? If the problem state variation of the TCPIP instruction is desired, then after having enabled the supervisor state flavor as described above, the command:
```
??????????????? facility enable HERC_TCPIP_PROB_STATE
```
must then _also_ be issued before IPLing the operating system.





regards;

Rahim 
?? 

?? 

On Saturday, December 26, 2020, 10:27:25 AM CST, Pedro Pinheiro <prppedro@...> wrote:

Hi, all

I have a rather dumb question, I recognize. But I've been struggling with it for the past day. There's a data set (CENTER.PARMLIB) in which TCPPROF member is contained. TSO MVSCUST opens this file for me. And I can also access it through DSLIST. Though I can't access it anywhere. Any other ISPF utilities just tells me either the “Data set is not cataloged” or (if I specify the volume) “Data set is not found”.

That's quite problematic because, on top of all that, system have been abending on me, crying 'bout lack of space in the dataset. But I can't edit CENTER.PARMLIB allocation because all the tools which seems to deal with that can't find the data set. Also, when using the “ALLOC” command, it infers the dataset is prefixed the current login, SYSPROG1.

So, is there any way out of this mess?

Thanks,

Att.,

-trp

Re: Difficulties with TCP/IP and data sets

#1944

TSO PROFILE NOPREFIX.

Then try to access ?your dataset.

Joe

Show quoted text

On Sat, Dec 26, 2020 at 10:27 AM Pedro Pinheiro <prppedro@...> wrote:

Hi, all

I have a rather dumb question, I recognize. But I've been struggling with it for the past day. There's a data set (CENTER.PARMLIB) in which TCPPROF member is contained. TSO MVSCUST opens this file for me. And I can also access it through DSLIST. Though I can't access it anywhere. Any other ISPF utilities just tells me either the “Data set is not cataloged” or (if I specify the volume) “Data set is not found”.

That's quite problematic because, on top of all that, system have been abending on me, crying 'bout lack of space in the dataset. But I can't edit CENTER.PARMLIB allocation because all the tools which seems to deal with that can't find the data set. Also, when using the “ALLOC” command, it infers the dataset is prefixed the current login, SYSPROG1.

So, is there any way out of this mess?

Thanks,
Att.,
-trp

Re: Working with ISAM Data Sets

#1943

Yeah ... DONT use ISAM. You will regret?it if you do so.

USE VSAM KSDS instead. Easier and less complicated. If you need some pointers let me know.

Joe

Show quoted text

On Sat, Dec 26, 2020 at 9:59 AM Patrik Schindler <poc@...> wrote:

Hello,

"The records that comprise a newly created data set must be presented for writing in ascending order by key."

Source:

Does this mean that I need to at least write one record with some arbitrary key value, and later (DISP=MOD) can add more records which are not necessarily in order with the key value already in the first record?

I want to find some practical use for a batch workflow involving collection of data and generating reports of it in TK4-. I decided to postpone VSAM to later when I feel skilled enough to create interactive applications using KICKS.

Thanks!

:wq! PoC

Difficulties with TCP/IP and data sets

#1942

Hi, all

I have a rather dumb question, I recognize. But I've been struggling with it for the past day. There's a data set (CENTER.PARMLIB) in which TCPPROF member is contained. TSO MVSCUST opens this file for me. And I can also access it through DSLIST. Though I can't access it anywhere. Any other ISPF utilities just tells me either the “Data set is not cataloged” or (if I specify the volume) “Data set is not found”.

That's quite problematic because, on top of all that, system have been abending on me, crying 'bout lack of space in the dataset. But I can't edit CENTER.PARMLIB allocation because all the tools which seems to deal with that can't find the data set. Also, when using the “ALLOC” command, it infers the dataset is prefixed the current login, SYSPROG1.

So, is there any way out of this mess?

Thanks,

Att.,

-trp

Working with ISAM Data Sets

#1941

Hello,

"The records that comprise a newly created data set must be presented for writing in ascending order by key."

Source: 

Does this mean that I need to at least write one record with some arbitrary key value, and later (DISP=MOD) can add more records which are not necessarily in order with the key value already in the first record?

I want to find some practical use for a batch workflow involving collection of data and generating reports of it in TK4-. I decided to postpone VSAM to later when I feel skilled enough to create interactive applications using KICKS.

Thanks!

:wq! PoC

Re: Show disk usage in TK4-

#1940

When Hercules writes the data from memory cache to disk, it compresses
the data and writes at a new location.  The old location is marked as
available and the files is eventually compressed to remove unused
space resulting in a smaller file on the host.  An delete on the host
just marks the tracks as available in the VTOC (or free space map in
the VTOCINDEX).  An erase before delete would do both (I guess).

Mainframe programs that are I/O limited on actual hardware are CPU
limited on Hercules, since it has so much disk cache in memory.  Early
versions of Hercules did cause mainframe programs problems due to I/O
completing so fast.

Show quoted text

On Mon, Dec 21, 2020 at 6:38 AM Patrik Schindler <poc@...> wrote:

Hello Mike,

Am 20.12.2020 um 18:57 schrieb Mike Schwab <Mike.A.Schwab@...>:

Hercules CCKD(64) releases the space to condense the host file in the background.May I ask what exactly you mean by ?release“? Overwrite them with a constant value, so a high compression ratio is achieved?

On I/O-heavy loads, could it be beneficial to not use compression at all? Moshix (the mainframe video guy) claimed, that today, CPUs are so fast, that it barely matters. What’s your opinion?

:wq! PoC

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

Re: Show disk usage in TK4-

#1939

Hello Joe,

Am 21.12.2020 um 14:15 schrieb Joe Monk <joemonk64@...>:

"The space recovery routine relocates track or block group images towards the beginning of the file, causing free space to move towards the end of the file. When a free space reaches the end of the file, it 'falls off', that is, the file size is reduced."Thanks a lot, now it’s clear to me.

:wq! PoC

Re: Show disk usage in TK4-

#1938

Hercules uses PC based disk files. The format inside those PC based disk files is mainframe CKD or FBA.

The "host file" that Mike was referring to is the PC based disk file. Since there is no need to statically allocate the entirety?of the DASD space (called "thin provisioning" in SAN land), the hercules disk process can dynamically allocate and release space from its emulated mainframe DASD files without issue...

"The space recovery routine relocates track or block group images towards the beginning of the file, causing free space to move towards the end of the file. When a free space reaches the end of the file, it 'falls off', that is, the file size is reduced."

Joe

Show quoted text

On Mon, Dec 21, 2020 at 6:38 AM Patrik Schindler <poc@...> wrote:

Hello Mike,

Am 20.12.2020 um 18:57 schrieb Mike Schwab <Mike.A.Schwab@...>:

> Hercules CCKD(64) releases the space to condense the host file in the background.

May I ask what exactly you mean by ?release“? Overwrite them with a constant value, so a high compression ratio is achieved?

On I/O-heavy loads, could it be beneficial to not use compression at all? Moshix (the mainframe video guy) claimed, that today, CPUs are so fast, that it barely matters. What’s your opinion?

:wq! PoC

Re: Show disk usage in TK4-

#1937

Hello Mike,

Am 20.12.2020 um 18:57 schrieb Mike Schwab <Mike.A.Schwab@...>:

Hercules CCKD(64) releases the space to condense the host file in the background.May I ask what exactly you mean by ?release“? Overwrite them with a constant value, so a high compression ratio is achieved?

On I/O-heavy loads, could it be beneficial to not use compression at all? Moshix (the mainframe video guy) claimed, that today, CPUs are so fast, that it barely matters. What’s your opinion?

:wq! PoC

Re: Show disk usage in TK4-

#1936

Jeffrey Melton wrote:

But regardless of whether you actually have physical
"wasted" space on your real disk drive ...[...]
Just making sure I understand the ramifications of all
this correctly,Precisely! You understand the situation perfectly.

Using an inefficient block size will waste space on the volume, causing it to hold less data than it otherwise could. The operating system would not be able to fit as much data on the volume (dasd) than it otherwise could have fit had a more efficient block size been chosen, and this is *regardless* of whether the dasd is a Hercules uncompressed CKD dasd or a compressed CCKD/CCKD64 dasd, because Hercules DOES strictly enforce an emulated dasd device type's maximum track size limitation.

-- 
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Re: Show disk usage in TK4-

#1935

开云体育

Exactly correct.? You’ve got it.

?

Peter

?

Show quoted text

From: [email protected] <[email protected]> On Behalf Of Jeffrey Melton via groups.io
Sent: Monday, December 21, 2020 1:20 AM
To: [email protected]
Subject: Re: [H390-MVS] Show disk usage in TK4-

?

But regardless of whether you actually have physical "wasted" space on your real disk drive by using compressed virtual devices, if you choose a suboptimal block size, you still won't be making the most of the (even compressed) virtual devices you do allocate in your IOGEN, correct?? Granted there is a tradeoff, but say you really screw up and set up a terrible block size for your files that causes MVS to "waste" half of the "available" space of a given virtual DASD.? Compressed or non-compressed, that would still mean that MVS thinks that virtual device is "full" when it really isn't, it's just that the existing files are allocated terribly out of whack, and you'll end up having to create and maintain more virtual "devices" in your emulated mainframe's IOGEN than would normally be necessary, correct?

Just making sure I understand the ramifications of all this correctly,

Jeff.?

--._,_._,_

Re: Show disk usage in TK4-

#1934

But regardless of whether you actually have physical "wasted" space on your real disk drive by using compressed virtual devices, if you choose a suboptimal block size, you still won't be making the most of the (even compressed) virtual devices you do allocate in your IOGEN, correct?? Granted there is a tradeoff, but say you really screw up and set up a terrible block size for your files that causes MVS to "waste" half of the "available" space of a given virtual DASD.? Compressed or non-compressed, that would still mean that MVS thinks that virtual device is "full" when it really isn't, it's just that the existing files are allocated terribly out of whack, and you'll end up having to create and maintain more virtual "devices" in your emulated mainframe's IOGEN than would normally be necessary, correct?

Just making sure I understand the ramifications of all this correctly,

Jeff.?

Re: Show disk usage in TK4-

#1933

On 2020-12-21 4:57 AM, Mike Schwab wrote:
There are some
programs that can go through and erase empty tracks later.Somitw's EOFDISK is one such program.

Basically you point a DD to a temporary data set, and it clears each track allocated to that data set.

Cheers,
Greg

Re: Show disk usage in TK4-

#1932

Normally, the track is not erased on delete.  It is a rarely used
option on VSAM files because it can take a while.  There are some
programs that can go through and erase empty tracks later.  Hercules
CCKD(64) releases the space to condense the host file in the
background.

Show quoted text

On Sun, Dec 20, 2020 at 10:54 AM Patrik Schindler <poc@...> wrote:

Hello David,

Am 13.12.2020 um 22:27 schrieb Fish Fish <david.b.trout@...>:

We're of course ignoring the compressed dasd image "free space" issue here as it has nothing to do with track blocksize efficiency. Free space is just an artifact (overhead) of Hercules's compressed dasd design.First, thanks for your explanation. Second, do I understand right, that a freed track’s data isn’t zeroed out, so overall compression ratio is worse than it could probably be?

Just a thought. With today’s actual disk sizes, the question is a more academic one than anything else.

:wq! PoC

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?