Re: problem meet when run dfsmsdss restore
HI,
is the data you are restoring from the same device type as you are restoring too ?
Your target is a 3390, is the source dumped from a 3390 ?
I think that DFSMSdss doesn't convert from one device type to another but expects them to be the same CC HH configuration.
It's a long time since I did dump / restore of this type, I understand it can be faster than doing it by datasets, but
restoring datasets can cross disk types and add them to the vtoc as it does it.
If the restore tape you are using contains a vtoc then the dasd is probably going to be mis-configured
because you have already configured a vtoc, and I doubt that having 2 vtoc's will work.
Regards,
Tom.
|
Re: IEHMOVE fails with IEH453I DATA SET SYS3.TESTPDS.ASM NOT MOVED/COPIED BECAUS TO DATA SET PREVIOUSLY RACF DEFINED
Hi Clem,
this is a distant memory, so may not work
add ,COPYAUTH to the command
Update: Another colleague suggested defining your TO dataset identically before issuing the command, then COPYAUTH should not be needed
Regards,
Tom
|
IEHMOVE fails with IEH453I DATA SET SYS3.TESTPDS.ASM NOT MOVED/COPIED BECAUS TO DATA SET PREVIOUSLY RACF DEFINED
Hi,
I am trying to run a very simple IEHMOVE but I get a RAKF error in TK5.? The message is:
IEH453I DATA SET SYS1.MACLIB NOT MOVED/COPIED BECAUSE?TO DATA SET PREVIOUSLY RACF DEFINED.
The output data set is not not there, and the User has all the privileges I can give it.? ?That is, it is like Herc01 and has all the RAKF facilities.
Thanks,
?
Clem Clarke
The JCL is:
//CLARKE0 JOB (ACCNT),NAME,MSGLEVEL=(1,1),NOTIFY=SYS3,? ? ? ? ? ?
//? MSGCLASS=X? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
//STEP1 EXEC PGM=IEHMOVE? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
//SYSPRINT DD SYSOUT=*? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
//SYSUT1 DD UNIT=3390,SPACE=(TRK,30)? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
//DISK01 DD VOL=SER=WORK01,DISP=OLD,UNIT=SYSDA? ? ? ? ? ? ? ? ? ?
//DISK02 DD VOL=SER=WORK02,DISP=OLD,UNIT=SYSDA? ? ? ? ? ? ? ? ? ?
//DISK03 DD VOL=SER=TK5RES,DISP=OLD,UNIT=SYSDA? ? ? ? ? ? ? ? ? ?
//SYSIN DD *? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?COPY TO=3390=WORK01,PDS=SYS1.MACLIB,RENAME=SYS3.TESTPDS3.ASM? ??
?
?
? ? ? ?
|
Eliminating duplicate records.
Hi folks.
I've been playing with OS-360 SORT for MVS 3.8.
Documentation is clear and, overall, I've been quite successful in sorting records (I feel I'm not handling 100% correctly my temporary datasets in JCL with PASS stuff etc, but overall, got it working).
However, as it came quite instinctively to my mind to wonder if I could get rid of duplicate records, I found that the SUM feature that I find everywhere when googling around the matter to be capable of doing that, is nowhere in the SORT program we have at hands (My guess is that the version of SORT we do have here maybe is a really very old one).
While I grasp there's some room for SORT to work together with other programs with all that exit routines stuff (way beyond my comprehension), I thought maybe someone has some clue how to handle such a trivial use-case (geting rid of duplicate records) under MVS 'the easy way'.
Thank you in advance.
Cheers.
|
problem meet when run dfsmsdss restore
hi all, i have built?4.6.0.10941-SDL-g65c97fd6 on?Linux-5.14.0-284.25.1.el9_2.x86_64. the hercules runs well. and i built an standalone ickdsf to initialize the cckd volume.? INIT UNITADDRESS(52C1) NOVERIFY VTOC(300,0,600) VOLID(DCAT50)
ICK003D REPLY U TO ALTER VOLUME 52C1 CONTENTS, ELSE T? ? ? ? ? ? ? ? ? ? ?
ENTER INPUT/COMMAND:? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
U? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
ICK31061I 52C1 VTOC INDEX CREATION SUCCESSFUL: VOLUME IS IN INDEX FORMAT??
ICK061I? ?52C1 VTOC INDEX CREATION SUCCESSFUL: VOLUME IS IN INDEX FORMAT??
ICK01317I VTOC-INDEX IS LOCATED AT CCHH=X'0154 0000' AND IS? ? 32 TRACKS.?
ICK01314I VTOC IS LOCATED AT CCHH=X'012C 0000' AND IS? ?600 TRACKS.? ? ? ?
ICK00001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0? ? ? ? ? ? ? ??
? ? ? ? ? 14:35:28? ? 03/05/24? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? below tape is an aws tape converted by tapeconv.jcl? restore frmdv(tape) frmadr(0300) toadr(52C1) vfy(DCAT50)
?RESTORE FRMDV(TAPE) FRMADR(0300) TOADR(52C1) VFY(DCAT50)? ? ? ? ? ? ? ? ? ? ? ?
ADRY0500I NEXT TRACK TO WRITE:? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? TRACK C:H = X'0000000:0'? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? 15:05:07? ? 03/05/24? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
ADRY2765I 52C1 INVALID TRACK FORMAT? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
CSW = 05D9D0 0E000000? ?CCW = 1D12B288 4000E4A6? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
SENSE = 00400000 00FFFF00 00000000 00000000 00000000 00000000 00000080 00001206?
ADRY0700I 52C1 TRACK CCHH = X'0012 0006'? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
ADRY2765I 52C1 INVALID TRACK FORMAT? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
CSW = 05DA20 0E000000? ?CCW = 1D1302DD 4000F1EF? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
SENSE = 00400000 00FFFF00 00000000 00000000 00000000 00000000 00000080 00006C06?
ADRY0700I 52C1 TRACK CCHH = X'006C 0006'? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
ADRY3818I 52C1 INCORRECT LENGTH? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
CSW = 05DA68 0E40082C? ?CCW = 9E000000 5000082C? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
SENSE = 00080000 00FFFF00 00000000 00000000 00000000 00000000 00000080 00006C0C?
ZARCHITECTURE? 5650-ZOS DFSMSDSS STAND-ALONE V2.02.0? ? ? ? ? ? ? TIME: 15:04:55
? ? ? ? 03/05/24? ? ?PAGE? ?2? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
ADRY0700I 52C1 TRACK CCHH = X'006C 000C'? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
ADRY3003I FUNCTION TERMINATED. CONDITION CODE IS 12? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
[root@lx-hemu-app-u1 ~]# sh /home/hyperion/cckdcdsk -f -3 /home/hercules/volume/DASD/DCAT50.52C1
HHC02499I Hercules utility lt-cckdcdsk - DASD CCKD image verification - version 4.6.0.10941-SDL-g65c97fd6
HHC01414I (C) Copyright 1999-2023 by Roger Bowler, Jan Jaeger, and others
HHC01417I ** The SDL 4.x Hyperion version of Hercules **
HHC01415I Build date: Feb? 6 2024 at 18:15:52
HHC00379I 0:0000 CCKD file /home/hercules/volume/DASD/DCAT50.52C1: starting lt-cckdcdsk level 3...
HHC00371W 0:0000 CCKD file /home/hercules/volume/DASD/DCAT50.52C1: trk[746] offset 0x00000000000B80D8 len 6237 validation error
HHC00007I Previous message from function 'cckd_chkdsk' at cckdutil.c(1858)
HHC00371W 0:0000 CCKD file /home/hercules/volume/DASD/DCAT50.52C1: trk[779] offset 0x00000000000C0726 len 5320 validation error
HHC00007I Previous message from function 'cckd_chkdsk' at cckdutil.c(1858)
HHC00371W 0:0000 CCKD file /home/hercules/volume/DASD/DCAT50.52C1: trk[1626] offset 0x0000000000114547 len 2987 validation error
HHC00007I Previous message from function 'cckd_chkdsk' at cckdutil.c(1858)
HHC00371W 0:0000 CCKD file /home/hercules/volume/DASD/DCAT50.52C1: trk[1631] offset 0x0000000000119571 len 10885 validation error
HHC00007I Previous message from function 'cckd_chkdsk' at cckdutil.c(1858)
HHC00373I 0:0000 CCKD file /home/hercules/volume/DASD/DCAT50.52C1: 0 trk images recovered
HHC00377I 0:0000 CCKD file /home/hercules/volume/DASD/DCAT50.52C1: free space rebuilt
HHC00380W 0:0000 CCKD file /home/hercules/volume/DASD/DCAT50.52C1: lt-cckdcdsk level 3 complete; rc=2
HHC00007I Previous message from function 'main' at cckdcdsk.c(149)
part? config as below:
? CPUSERIAL 002623? ? ? ? ? ? ? # CPU serial number
# CPUMODEL? 3090? ? ? ? ? ? ? ? # CPU model number
? CPUMODEL? 8562? ? ? ? ? ? ? ? # CPU model number
? MODEL? ? ?L01? ? ? ? ? ? ? ? ?# STSI returned model
? PLANT? ? ?ZZ? ? ? ? ? ? ? ? ? # STSI returned plant
? MANUFACTURER HRC? ? ? ? ? ? ? # STSI returned manufacturer
# LPARNAME? HERCULES? ? ? ? ? ? # DIAG 204 returned lparname
? LPARNAME? DEVE? ? ? ? ? ? ? ? # DIAG 204 returned lparname
? CPUVERID? 00? ? ? ? ? ? ? ? ? # CPU Version Identification
# MAINSIZE? 64? ? ? ? ? ? ? ? ? # Main storage size in megabytes
? MAINSIZE? 8192? ? ? ? ? ? ? ? # Main storage size in megabytes
? XPNDSIZE? 0? ? ? ? ? ? ? ? ? ?# Expanded storage size in megabytes
# NUMCPU? ? 1? ? ? ? ? ? ? ? ? ?# Number of CPUs
? NUMCPU? ? 8? ? ? ? ? ? ? ? ? ?# Number of CPUs
# NUMVEC? ? 1? ? ? ? ? ? ? ? ? ?# Number of Vector Processors
# MAXCPU? ? 8? ? ? ? ? ? ? ? ? ?# Maximum number of CPUs
? MAXCPU? ? 8? ? ? ? ? ? ? ? ? ?# Maximum number of CPUs
? ARCHLVL? ?z/Arch? ? ? ? ? ? ? # Architecture mode S/370, ESA/390 or z/Arch
? FACILITY? DISABLE 006_ASN_LX_REUSE? ?# ASN-and-LX-Reuse facility
# ECPSVM? ? DISABLE? ? ? ? ? ? ?# VM Assist : NO or Level (20 recommended)
# LOADPARM? 0120....? ? ? ? ? ? # IPL parameter
? LOADPARM? 52C109M.? ? ? ? ? ? # IPL parameter
# OSTAILOR? LINUX? ? ? ? ? ? ? ?# OS tailoring
? OSTAILOR? z/OS? ? ? ? ? ? ? ? # OS tailoring
? SYSEPOCH? 1900? ? ? ? ? ? ? ? # Base year for initial TOD clock
# TZOFFSET? +0200? ? ? ? ? ? ? ?# Using UTC (GMT)
? TZOFFSET? +0800? ? ? ? ? ? ? ?# Using UTC (GMT)
?
? 0300? ? 3590? ? /home/hercules/volume/TAPE/100001.tap ? 52C1? ? 3390? ? /home/hercules/volume/DASD/DCAT50.52C1 any suggestion is? much?appreciated!
|
Re: Hercules Error Messages Undocumented??
Please post your config file for both instances of hercules ... the one on the MAC and the one on Windows.
Joe
I am getting multiple error messages whhen trying to connect several very much working volumes on a shared configuration on Windows, but unable to connect to the same volumes on my Mac/Parallels Windows 11. Would someone please tell me where I can find current documentation for Hercules 4.6 errors. Some of the messages are:
HHC00726E 0:0AA4 Shared: remote error F7-E0: device not found
HHC00007I Previous message from function 'clientRecv' at shared.c(1464)
HHC00721I 0:0AA4 Shared: connected to v14.0 server id 0 file 192.168.12.85:3990:504
HHC00726E 0:0AA4 Shared: remote error F3-EC: not a connect request
HHC00007I Previous message from function 'clientRecv' at shared.c(1464)
HHC00726E 0:0AA4 Shared: remote error F3-EB: not a connect request
HHC00007I Previous message from function 'clientRecv' at shared.c(1464)
HHC00702S 0:0AA4 Shared: error retrieving cylinders
HHC00007I Previous message from function 'shared_ckd_init' at shared.c(231)
HHC00401E 0:0AA4 CKD file 192.168.12.85:3990:504: open error: not found
from the log file. If I could find the documentation for the messages, I could probably resolve the problem. If not, what documentation must I provide to the support team. I have multiple configuration files, log files, and directories where the emulated DASD reside. As I said, all volumes are usable on one of my TK-5 systems and my z/OS system running on Windows 10.
|
Re: COBOL Sort - - +IER040A - INSUFFICIENT WORK UNITS
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Tom Armstrong Sent: Friday, March 1, 2024 7:43 PM To: [email protected]Subject: Re: [H390-MVS] COBOL Sort - - +IER040A - INSUFFICIENT WORK UNITS ? Hi Guys,
My suggestion is that if you have migrated to TK5 then take advantage of the enhancements with OS/360 Sort/Merge for MVS 3.8. Just delete all SORTWKxx DD statements in sorting steps, COBOL invoked or direct invokation of the Sort/Merge program. The default setting for the new Sort/Merge program is to dynamically allocate SORTWKxx data sets. This simplifies JCLrequirements. A SORTLIB DD statement is still required, and if Sort/Merge message options select the printer, then a SYSOUT DD statement is also required.
2314 DASD is no longer required in the TK5 environment.
Regards
Tom
|
Re: COBOL Sort - - +IER040A - INSUFFICIENT WORK UNITS
Hi Guys,
My suggestion is that if you have migrated to TK5 then take advantage of the enhancements with OS/360 Sort/Merge for MVS 3.8. Just delete all SORTWKxx DD statements in sorting steps, COBOL invoked or direct invokation of the Sort/Merge program. The default setting for the new Sort/Merge program is to dynamically allocate SORTWKxx data sets. This simplifies JCLrequirements. A SORTLIB DD statement is still required, and if Sort/Merge message options select the printer, then a SYSOUT DD statement is also required.
2314 DASD is no longer required in the TK5 environment.
Regards
Tom
|
Re: Cross Memory Address space data exchange/communication
On 2/03/2024 1:01 am, Bob Polmanter wrote: Rather, the ENQ's purpose is simply to place a QCB entry into the system, so the QCB chain can be searched to identify NJE38's outstanding ENQ and grab the Rname data from it. The classic way a lot of program products flagged their presence was to add their own subsystem to the SSCT (SSCVT?) chain.? They offered no subsystem services as such but used the SSCT (via the SSCTUSE field most often) to anchor global data structures making them available to all address spaces. This problem was eventually solved "properly" by Name/Token Services which offers name/token pairs at the task, address space and system levels. Cheers, Greg
|
Re: Cross Memory Address space data exchange/communication
Dear Bob, Mark, Dennis, Jo?o, Silvio and Wally,
I'm simply overwhelmed by the number of responses on my initial post and the pointers in various directions. Lot's of ideas to delve deeper into as well as having a closer look at NJE38's source code as Bob suggested. Bob's post illustrates to me the solution to the hen/egg problem: how to tell some other address space what the address of e.g. an ECB or some other structure in common storage is. If I get it right Bob is using the XM Post ENQ/DEQ pattern to pass small tokens of information from the client to the server while the massive data is passed through spooling on disk.?
It's not only out of curiosity I'm looking for this information. However, for the time being my assembler skills are merely useful for doing some brain jogging (one has to remember the current use of all those registers :-) ) rather than being able to implement something really useful.
Bob's NJE38 lured me into envisioning something really daring (for my skill level) but that's for a different topic.?
I learned that fiddling with SRB is not for the faint-hearted. Tommy Sprinkle hinted in his MVS Systems programming that one could easily take down the entire system but that's probably also due to the need of running in supervisor mode.?
Again, thanks to everybody for the input.?
hugs and kisses
Michael
--
TK4- on virtual x86 Ubuntu LTS 22.04
VM/370 on virtual x86 Ubuntu LTS 22.04
Die Katze l?sst das Mausen nicht,
Die Jungfern bleiben Coffeeschwestern.
Die Mutter liebt den Coffee Brauch,
Die Gro?mama trank solchen auch.
Wer will da auf die T?chter l?stern?
J.S.Bach "Kaffee-Kantate" (BWV 211)
|
Re: COBOL Sort - - +IER040A - INSUFFICIENT WORK UNITS
Frank, if you enter /d u on the hercules montor, you will see:- 130 2314 OFFLINE 131 2314 OFFLINE 132 2314 OFFLINE 133 2314 OFFLINE 134 2314 OFFLINE 135 2314 OFFLINE 136 2314 OFFLINE 137 2314 OFFLINE 138 2314 OFFLINE 139 2314 OFFLINE 13A 2314 OFFLINE 13B 2314 OFFLINE 13C 2314 OFFLINE 13D 2314 OFFLINE 13E 2314 OFFLINE 13F 2314 OFFLINE Chris -- <cjar1950@...> ---------------------------------------------------------------------------------------------------------------------------------- On Fri, 1 Mar 2024 08:44:27 -0500 "Frank D. Engel, Jr." <fde101@...> wrote: Do you happen to know what CUUs are defined for 2314 in TK5?
I did add 2314s to my config and was able to create VTOCs on them but they are not mounting.
Even if they are no longer required I would be interested in completing the exercise of getting these added if only for educational/experience purposes.
On 3/1/24 07:32, Ed Liss wrote:
On Wed, Feb 28, 2024 at 07:42 AM, Dagfinn Hammar wrote:
Is this a general problem with TK5 that makes it difficult to use
cobol/sort/merge or have Rob Prince made a different solution with
the new DASD's?in TK5.
It seems you have followed the steps to add these sort DASD
correctly. The adding of these files to the TK5 config is also
needed but you may already have done this. If so I think Rob can
help you with?this better than anyone.
The problem is the UNIT=2314 in the JCL.? The sort/merge utility in
TK5 works with any DASD.? Try UNIT=SYSDA in your jcl since TK5 does
not have 2311 or 2314 volumes defined in the Hercules config files.?
Yes, the IOGEN has the 23xx units defined but the Hercules config does
not define any 23xx units.
When I converted from Tk4 to TK5, all I had to do to get the sort to
work was change UNIT=2314 to UNIT=SYSDA in the JCL.
|
Re: Cross Memory Address space data exchange/communication
Hi Wally and Silvio,
In NJE38's case, the ENQ is not used for serialization at all.? No other ENQs are issues by any NJE38 component.? Rather, the ENQ's purpose is simply to place a QCB entry into the system, so the QCB chain can be searched to identify NJE38's outstanding ENQ and grab the Rname data from it.
As for CVTUSER, I have always resisted using this field as well as TCBUSER or ASCBUSER.? One can never be certain whether some other piece of software is going to also use it.?? If NJE38 did use CVTUSER, then anyone running Silvio's XM POST program (for example) would cripple NJE38.?? With all of the software written for TK3, TK4 and TK5 over the years, I can't be certain of what is out there.? For me personally, using these fields is risky and I don't do it.
I also chose to obtain my CSA data areas in key 0, so that an unauthorized program could not alter it, either deliberately or by accident.?? In z/OS nowadays, you cannot obtain storage in CSA in a user key. This security hole was closed.? MVS 3.8 still allows user key CSA storage but it doesn't mean we have to use it.
Regards,
Bob
|
Re: COBOL Sort - - +IER040A - INSUFFICIENT WORK UNITS
Do you happen to know what CUUs are defined for 2314 in TK5?
I did add 2314s to my config and was able to create VTOCs on them
but they are not mounting.
Even if they are no longer required I would be interested in
completing the exercise of getting these added if only for
educational/experience purposes.
On 3/1/24 07:32, Ed Liss wrote:
toggle quoted message
Show quoted text
On Wed, Feb 28, 2024 at 07:42 AM, Dagfinn Hammar wrote:
Is this a general problem with TK5 that makes it
difficult to use cobol/sort/merge or have Rob Prince made a
different solution with the new DASD's?in TK5.
?
It seems you have followed the steps to add these sort DASD
correctly. The adding of these files to the TK5 config is also
needed but you may already have done this. If so I think Rob
can help you with?this better than anyone.
?
The problem is the UNIT=2314 in the JCL.? The sort/merge utility
in TK5 works with any DASD.? Try UNIT=SYSDA in your jcl since TK5
does not have 2311 or 2314 volumes defined in the Hercules config
files.? Yes, the IOGEN has the 23xx units defined but the Hercules
config does not define any 23xx units.
When I converted from Tk4 to TK5, all I had to do to get the sort
to work was change UNIT=2314 to UNIT=SYSDA in the JCL.
|
Re: Cross Memory Address space data exchange/communication
The ENQ/DEQ is not to serialize the request but to save the CSA ECB address in the RNAME.
You need it in order to use the cross memory POST/WAIT.
In z/OS V2 you can use a TOKEN instead of ENQ/DEQ to save it until you delete the TOKEN and free the CSA.. ? ? Dear all,
I did multiple implementations of Cross memory communications. To give some concrete idea how to bring the very good theory from the posts in this area here in the group, I include a txt file with 3 code snippets.
The first is a simple SVC that creates a "user CVT" and puts the address in the CVTUSER field as was mentioned earlier by Dennis. You might wonder why the GETMAIN for the area looks somewhat complicated. I allocate the area in common storage, subpool 228 and Key=8. Unfortunately there is no easy way to specify the Storage-Key in a "normal" GETMAIN macro. so I had to use the branch entry and since I ask for common storage it's necessary to get the global lock first. The reason for Key=8 is that it allows the users to modify the area or wait on an ECB without the need to use a MODESET KEY=ZERO which needs at least APF authorization.?
Code snippet 2 is from a "server" program that initializes a communication area with ECB's and put the address in the
user CVT.
Finally the last excerpt is from a "client" that builds a "request" and hand it over by a cross memory post.?
In my case the implementation is architecturally limited to 1:1 communication, so there was no need to?
surround it with ENQ/DEQ to serialize the "client" cross memory post.
Silvio
PS: I am not native in english language, so it might sound rather rusty sometimes. Sorry for that.? -- att. Jo?o
|
Re: COBOL Sort - - +IER040A - INSUFFICIENT WORK UNITS
On Wed, Feb 28, 2024 at 07:42 AM, Dagfinn Hammar wrote:
Is this a general problem with TK5 that makes it difficult to use cobol/sort/merge or have Rob Prince made a different solution with the new DASD's?in TK5.
?
It seems you have followed the steps to add these sort DASD correctly. The adding of these files to the TK5 config is also needed but you may already have done this. If so I think Rob can help you with?this better than anyone.
?
The problem is the UNIT=2314 in the JCL.? The sort/merge utility in TK5 works with any DASD.? Try UNIT=SYSDA in your jcl since TK5 does not have 2311 or 2314 volumes defined in the Hercules config files.? Yes, the IOGEN has the 23xx units defined but the Hercules config does not define any 23xx units. When I converted from Tk4 to TK5, all I had to do to get the sort to work was change UNIT=2314 to UNIT=SYSDA in the JCL.
|
Re: Cross Memory Address space data exchange/communication
Dear all,
I did multiple implementations of Cross memory communications. To give some concrete idea how to bring the very good theory from the posts in this area here in the group, I include a txt file with 3 code snippets.
The first is a simple SVC that creates a "user CVT" and puts the address in the CVTUSER field as was mentioned earlier by Dennis. You might wonder why the GETMAIN for the area looks somewhat complicated. I allocate the area in common storage, subpool 228 and Key=8. Unfortunately there is no easy way to specify the Storage-Key in a "normal" GETMAIN macro. so I had to use the branch entry and since I ask for common storage it's necessary to get the global lock first. The reason for Key=8 is that it allows the users to modify the area or wait on an ECB without the need to use a MODESET KEY=ZERO which needs at least APF authorization.?
Code snippet 2 is from a "server" program that initializes a communication area with ECB's and put the address in the
user CVT.
Finally the last excerpt is from a "client" that builds a "request" and hand it over by a cross memory post.?
In my case the implementation is architecturally limited to 1:1 communication, so there was no need to?
surround it with ENQ/DEQ to serialize the "client" cross memory post.
Silvio
PS: I am not native in english language, so it might sound rather rusty sometimes. Sorry for that.?
|
Re: Cross Memory Address space data exchange/communication
Instead of using ENQ a better way to is to use 2 different ECBs. ? The caller POSTs the first one and then WAITs on the second. The request processor just does the opposite. ? Wally ? ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Dennis Stone Sent: Thursday, February 29, 2024 04:38 PM To: [email protected]Subject: Re: [H390-MVS] Cross Memory Address space data exchange/communication ? Hi all,
I just wanted to add a little to this conversation. Another way to pass the address of the CSA area is to utilize the CVTUSER field in the CVT. We did this at a former job. We would allocate what we called a vector table in CSA and put that address in the CVTUSER field. That table would then contain addresses of any number of CSA areas for any number of uses. We created a macro that mapped the vector table and it is a simple matter to get this address from the CVT.
Just offering another option.
Thanks,
Dennis On 2/29/24 14:47, Bob Polmanter wrote: Hi Michael,
To follow on with what Mark posted, there are other ways to perform cross-memory (XM) communication that do not need SRBs.? Everything Mark posted is correct.? But there are easier ways.? SRBs are a whole other animal and have a litany of rules and regulations in order to use them or issue macros from them.? For example, you can't just issue a POST macro from an SRB? (because POST issues an SVC instruction, which are taboo in SRBs) so you have to use a special interface called 'branch entry to POST'.? And depending on what kind of POST you need issued, you may have to issue a SETLOCK macro in the SRB as well, and so on and so forth.? It often just gets more complex.
Fortunately, in MVS 3.8 a cross-memory POST (XM POST) is provided and can be issued from user programming without needing SRBs.
Whether you use XM POST directly or use an SRB to do it for you, one of the big problems of getting XM communication established is how do you let the other address space know where (address) your ECB is located.? Common storage (CSA) is your friend.
So using CSA, you can set up a small storage area that would be addressable to all address spaces, and this area can contain your ECB, and some space for control information or whatever message you wish to pass along to the other address space when you post the ECB.? This 'other address space' has issued a WAIT against that ECB, waiting for someone to POST it and pass the message along.
The remaining problem is how to tell the other address spaces that will be POSTing this ECB exactly where this storage area is located.? One way to do this is using an ENQ macro.? So the creator of the CSA storage area (usually the address space that will be WAITing on the ECB), creates the area and initializes it, and then issues an ENQ macro with the Rname field containing the CSA storage address of the area.? The Qname field is some unique name that other address spaces can search for.? Once the ENQ is issued, the system puts the Qname and Rname values in a queue of all of the ENQs currently issued.? It is a simple search to locate this queue and look for the Qname that the creator used and once you find that then the Rname is right there.? You now have the address of the storage area and you could issue XM POST to wake up the creator.?
I realize this is somewhat simplified and glossed over rather quickly.? But, you have the actual code available that you can look at where these things are done:? NJE38.? In the source code, the NJE38 started-task is the creator, and it builds a CSA area and issues the ENQ.? Then other address spaces like a TSO user who is doing a TRANSMIT command will eventually search the ENQ queue to find NJE38's QNAME/RNAME and get the CSA address, so it can issue XM POST to let NJE38 know that a new file as been placed in the NJE38 spool and is ready for transmission.? NJE38 wakes up from the post and sees the request and begins its work to transmit the file to another node, if it can.
In addition to just issuing XM POST to wake up NJE38, these other address spaces that wish to wake up NJE38 also put some control information in CSA as well, which I call a 'work request' so that when NJE38 wakes up it sees the work request and then knows why it was woken up and can begin to process it.? So TSO TRANSMIT for example:
1. writes the file to be transmitted to the NJE38 spool.
2. Looks up "NJE38" QNAME in the ENQ queues.
3. Creates a work request in CSA and marks it up with "new spool file available" in essence.
4. Issues XM POST against the ECB in the CSA that was identified by the NJE38 QNAME.
When NJE38 is done processing the work request, it FREEMAINs the work request in CSA (that TRANSMIT created) and goes back to sleep with another WAIT on that same ECB in CSA.
In this way many address spaces can communicate with a single 'mother task' such as NJE38.? It makes NJE38 a type of server, and TSO users are a type of client.? A batch job can also be a client (or a server too; it is all in how you set it up and for what purpose).
The macros discussed here and in Mark's prior post, such as SRB, SETLOCK, POST (including XM POST) are documented in GC28-0628-3 OS/VS2 System Programming Library: Supervisor.? Note, XM post is not a unique macro; it is the same old POST macro used for everything else.? It just has additional parameters that have to be specified to make it a XM POST.? If you look in NJE38 source for these POSTs, I call them CM POST usually, not XM POST, in the comments.? The code to create the CSA area and issue the ENQ is close to the beginning of module NJEINIT.? The code to search the ENQ queues is in NJESYS.? The code for TRANSMIT (NJETRN) as previously mentioned also calls NJESYS to search the queues and then issue XM POST.
In modern times, such as with z/OS, XM communication is much easier because of new facilities available to facilitate it, but I'm not going to get into it here.? The methods are the same, e.g., XM POSTing ECBs, and using CSA, as well as new stuff like primary/secondary address spaces, access registers, name/token pairs, and lots more.? But we have to use what MVS 3.8 offers us and work around the limitations.
Regards,
Bob
?
|
Re: Cross Memory Address space data exchange/communication
Hi all,
I just wanted to add a little to this conversation. Another way to
pass the address of the CSA area is to utilize the CVTUSER field in
the CVT. We did this at a former job. We would allocate what we
called a vector table in CSA and put that address in the CVTUSER
field. That table would then contain addresses of any number of CSA
areas for any number of uses. We created a macro that mapped the
vector table and it is a simple matter to get this address from the
CVT.
Just offering another option.
Thanks,
Dennis
On 2/29/24 14:47, Bob Polmanter wrote:
toggle quoted message
Show quoted text
Hi Michael,
To follow on with what Mark posted, there are other ways to
perform cross-memory (XM) communication that do not need SRBs.?
Everything Mark posted is correct.? But there are easier ways.?
SRBs are a whole other animal and have a litany of rules and
regulations in order to use them or issue macros from them.? For
example, you can't just issue a POST macro from an SRB? (because
POST issues an SVC instruction, which are taboo in SRBs) so you
have to use a special interface called 'branch entry to POST'.?
And depending on what kind of POST you need issued, you may have
to issue a SETLOCK macro in the SRB as well, and so on and so
forth.? It often just gets more complex.
Fortunately, in MVS 3.8 a cross-memory POST (XM POST) is provided
and can be issued from user programming without needing SRBs.
Whether you use XM POST directly or use an SRB to do it for you,
one of the big problems of getting XM communication established is
how do you let the other address space know where (address) your
ECB is located.? Common storage (CSA) is your friend.
So using CSA, you can set up a small storage area that would be
addressable to all address spaces, and this area can contain your
ECB, and some space for control information or whatever message
you wish to pass along to the other address space when you post
the ECB.? This 'other address space' has issued a WAIT against
that ECB, waiting for someone to POST it and pass the message
along.
The remaining problem is how to tell the other address spaces that
will be POSTing this ECB exactly where this storage area is
located.? One way to do this is using an ENQ macro.? So the
creator of the CSA storage area (usually the address space that
will be WAITing on the ECB), creates the area and initializes it,
and then issues an ENQ macro with the Rname field containing the
CSA storage address of the area.? The Qname field is some unique
name that other address spaces can search for.? Once the ENQ is
issued, the system puts the Qname and Rname values in a queue of
all of the ENQs currently issued.? It is a simple search to locate
this queue and look for the Qname that the creator used and once
you find that then the Rname is right there.? You now have the
address of the storage area and you could issue XM POST to wake up
the creator.?
I realize this is somewhat simplified and glossed over rather
quickly.? But, you have the actual code available that you can
look at where these things are done:? NJE38.? In the source code,
the NJE38 started-task is the creator, and it builds a CSA area
and issues the ENQ.? Then other address spaces like a TSO user who
is doing a TRANSMIT command will eventually search the ENQ queue
to find NJE38's QNAME/RNAME and get the CSA address, so it can
issue XM POST to let NJE38 know that a new file as been placed in
the NJE38 spool and is ready for transmission.? NJE38 wakes up
from the post and sees the request and begins its work to transmit
the file to another node, if it can.
In addition to just issuing XM POST to wake up NJE38, these other
address spaces that wish to wake up NJE38 also put some control
information in CSA as well, which I call a 'work request' so that
when NJE38 wakes up it sees the work request and then knows why it
was woken up and can begin to process it.? So TSO TRANSMIT for
example:
1. writes the file to be transmitted to the NJE38 spool.
2. Looks up "NJE38" QNAME in the ENQ queues.
3. Creates a work request in CSA and marks it up with "new spool
file available" in essence.
4. Issues XM POST against the ECB in the CSA that was identified
by the NJE38 QNAME.
When NJE38 is done processing the work request, it FREEMAINs the
work request in CSA (that TRANSMIT created) and goes back to sleep
with another WAIT on that same ECB in CSA.
In this way many address spaces can communicate with a single
'mother task' such as NJE38.? It makes NJE38 a type of server, and
TSO users are a type of client.? A batch job can also be a client
(or a server too; it is all in how you set it up and for what
purpose).
The macros discussed here and in Mark's prior post, such as SRB,
SETLOCK, POST (including XM POST) are documented in GC28-0628-3
OS/VS2 System Programming Library: Supervisor.? Note, XM post is
not a unique macro; it is the same old POST macro used for
everything else.? It just has additional parameters that have to
be specified to make it a XM POST.? If you look in NJE38 source
for these POSTs, I call them CM POST usually, not XM POST, in the
comments.? The code to create the CSA area and issue the ENQ is
close to the beginning of module NJEINIT.? The code to search the
ENQ queues is in NJESYS.? The code for TRANSMIT (NJETRN) as
previously mentioned also calls NJESYS to search the queues and
then issue XM POST.
In modern times, such as with z/OS, XM communication is much
easier because of new facilities available to facilitate it, but
I'm not going to get into it here.? The methods are the same,
e.g., XM POSTing ECBs, and using CSA, as well as new stuff like
primary/secondary address spaces, access registers, name/token
pairs, and lots more.? But we have to use what MVS 3.8 offers us
and work around the limitations.
Regards,
Bob
|
Re: Cross Memory Address space data exchange/communication
Hi Michael,
To follow on with what Mark posted, there are other ways to perform cross-memory (XM) communication that do not need SRBs.? Everything Mark posted is correct.? But there are easier ways.? SRBs are a whole other animal and have a litany of rules and regulations in order to use them or issue macros from them.? For example, you can't just issue a POST macro from an SRB? (because POST issues an SVC instruction, which are taboo in SRBs) so you have to use a special interface called 'branch entry to POST'.? And depending on what kind of POST you need issued, you may have to issue a SETLOCK macro in the SRB as well, and so on and so forth.? It often just gets more complex.
Fortunately, in MVS 3.8 a cross-memory POST (XM POST) is provided and can be issued from user programming without needing SRBs.
Whether you use XM POST directly or use an SRB to do it for you, one of the big problems of getting XM communication established is how do you let the other address space know where (address) your ECB is located.? Common storage (CSA) is your friend.
So using CSA, you can set up a small storage area that would be addressable to all address spaces, and this area can contain your ECB, and some space for control information or whatever message you wish to pass along to the other address space when you post the ECB.? This 'other address space' has issued a WAIT against that ECB, waiting for someone to POST it and pass the message along.
The remaining problem is how to tell the other address spaces that will be POSTing this ECB exactly where this storage area is located.? One way to do this is using an ENQ macro.? So the creator of the CSA storage area (usually the address space that will be WAITing on the ECB), creates the area and initializes it, and then issues an ENQ macro with the Rname field containing the CSA storage address of the area.? The Qname field is some unique name that other address spaces can search for.? Once the ENQ is issued, the system puts the Qname and Rname values in a queue of all of the ENQs currently issued.? It is a simple search to locate this queue and look for the Qname that the creator used and once you find that then the Rname is right there.? You now have the address of the storage area and you could issue XM POST to wake up the creator.?
I realize this is somewhat simplified and glossed over rather quickly.? But, you have the actual code available that you can look at where these things are done:? NJE38.? In the source code, the NJE38 started-task is the creator, and it builds a CSA area and issues the ENQ.? Then other address spaces like a TSO user who is doing a TRANSMIT command will eventually search the ENQ queue to find NJE38's QNAME/RNAME and get the CSA address, so it can issue XM POST to let NJE38 know that a new file as been placed in the NJE38 spool and is ready for transmission.? NJE38 wakes up from the post and sees the request and begins its work to transmit the file to another node, if it can.
In addition to just issuing XM POST to wake up NJE38, these other address spaces that wish to wake up NJE38 also put some control information in CSA as well, which I call a 'work request' so that when NJE38 wakes up it sees the work request and then knows why it was woken up and can begin to process it.? So TSO TRANSMIT for example:
1. writes the file to be transmitted to the NJE38 spool.
2. Looks up "NJE38" QNAME in the ENQ queues.
3. Creates a work request in CSA and marks it up with "new spool file available" in essence.
4. Issues XM POST against the ECB in the CSA that was identified by the NJE38 QNAME.
When NJE38 is done processing the work request, it FREEMAINs the work request in CSA (that TRANSMIT created) and goes back to sleep with another WAIT on that same ECB in CSA.
In this way many address spaces can communicate with a single 'mother task' such as NJE38.? It makes NJE38 a type of server, and TSO users are a type of client.? A batch job can also be a client (or a server too; it is all in how you set it up and for what purpose).
The macros discussed here and in Mark's prior post, such as SRB, SETLOCK, POST (including XM POST) are documented in GC28-0628-3 OS/VS2 System Programming Library: Supervisor.? Note, XM post is not a unique macro; it is the same old POST macro used for everything else.? It just has additional parameters that have to be specified to make it a XM POST.? If you look in NJE38 source for these POSTs, I call them CM POST usually, not XM POST, in the comments.? The code to create the CSA area and issue the ENQ is close to the beginning of module NJEINIT.? The code to search the ENQ queues is in NJESYS.? The code for TRANSMIT (NJETRN) as previously mentioned also calls NJESYS to search the queues and then issue XM POST.
In modern times, such as with z/OS, XM communication is much easier because of new facilities available to facilitate it, but I'm not going to get into it here.? The methods are the same, e.g., XM POSTing ECBs, and using CSA, as well as new stuff like primary/secondary address spaces, access registers, name/token pairs, and lots more.? But we have to use what MVS 3.8 offers us and work around the limitations.
Regards,
Bob
|
Re: COBOL Sort - - +IER040A - INSUFFICIENT WORK UNITS
Hi I read Jay Moseley's FAQ about the cobol sort utility so that is why I was pre-allocating the files. When reading the cobol -74 manual I was able to sort out that it was not needed. The program from the manual works fine. So does the program I initially received the "insufficient work units" message from.
"Cobol -74 is portable."
Thanks again for all your help.
"Why do I receive the message:?IER040A INSUFFICIENT WORK UNITS?when I attempt to use the MVT Sort/Merge program under MVS 3.8?
The MVT Sort/Merge utility requires at least three (and may use up to a maximum of 32) intermediate storage datasets.? Unlike current Sort/Merge utilities (such as DFSORT or Syncsort), the MVT Sort/Merge is unable to dynamically allocate datasets for use as intermediate storage.? You must supply DD statements for the DD Names SORTWK01, SORTWK02, SORTWK03 ... SORTWK32.? Also the SORTWK?? datasets must reside on 2311/2314 DASD.? Although some efforts have been reported of using tape datasets with the MVT Sort/Merge under Hercules, it is probably a better idea to utilize DASD for the SORTWK?? datasets.? If the MVT Sort/Merge is called indirectly (as by a COBOL program that includes the SORT verb), you must also supply SORTWK?? DD cards to the EXEC step. [July 2020] If you are using an MVS system built following my?, there are six 2314 DASD volumes defined as SORTW1 through SORTW6 and are assigned with the esoteric device name SORTDA."
------------------------------------------------ Dagfinn D. Hammar
On Wed, 28 Feb 2024 at 17:21, Jeff Bassett < bassettj@...> wrote:
Dagfinn,
What is the purpose of the GO.SORTDD statement??
You are allocating a new data set ¨C but did NOT specify a volume serial
Also, you should NOT need a COB.SYSLIB ¨C this would be input to the COBOL step
?
?
Your GO.INDD and GO.OUT DD appear to be the input file and the output file
?
I see that you have made progress and I am replying to a previous post ¨C
I simply wanted to follow up with your question.?
?
-J-
?
Jeff Bassett
Bassettj@...
(301) 424-3362 (office)
(240) 388-7148 Cell
?
Time spent flying? - is
NOT deducted from one¡¯s lifespan
?
From: [email protected] <[email protected]>
On Behalf Of Dagfinn Hammar via
Sent: Wednesday, February 28, 2024 2:44 AM
To: [email protected]
Subject: Re: [H390-MVS] COBOL Sort - - +IER040A - INSUFFICIENT WORK UNITS
?
If i run this without the GO,SORTDD?statement?i get the following error:
+IER036I - B = ? 90 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
+IER037I - G = ?2488 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
+IER038I - NMAX = ? 88920 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
+IER046A - SORT CAPACITY EXCEEDED ? ? ? ? ? ? ? ? ? ? ? ? ?
+IER066A - APROX RCD CNT 0089011 ? ? ? ? ? ? ? ? ? ? ? ? ? ?
+IKF888I UNSUCCESSFUL SORT FOR SORTDA ? ? ? ? ? ? ? ? ? ? ?
+IEW1991 ERROR - USER PROGRAM HAS ABNORMALLY TERMINATED ? ?
IEF450I HERC0101 GO STEP06 - ABEND S0C4 U0000 - TIME=08.39.4
HERC0101 ? STEP06 ? ?GO ? ? ? ?LOADER ? ?AB S0C4 ? ? ? ? ? ?
IEF404I HERC0101 -?
?
On Wed, 28 Feb 2024 at 08:35, Dagfinn Hammar via <dagfinndh33=[email protected]> wrote:
Again - thank you for helping to solve this task. I have made some progress but receive a message about offline units needed. My jcl for cobol/sort and messages from sysout-console:
/* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
//COB.SYSLIB ?DD DSNAME=SYS1.COBLIB,DISP=SHR ? ? ? ? ? ? ? ? ? ? ? ?
//GO.SORTLIB ?DD DSNAME=SYS1.SORTLIB,DISP=SHR ? ? ? ? ? ? ? ? ? ? ? ?
//GO.SYSUDUMP DD SYSOUT=* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
//GO.SORTDD ? DD DSNAME=HERC01.TEST.SORT.FILE, ? ? ? ? ? ? ? ? ? ? ?
// ? ? ? ? ? ? DISP=(NEW,PASS,DELETE), ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
// ? ? ? ? ? ? DCB=(DSORG=PS,RECFM=FB,LRECL=80,BLKSIZE=800), ? ? ? ?
// ? ? ? ? ? ? UNIT=SORT,SPACE=(TRK,(200,1)) ? ? ? ? ? ? ? ? ? ? ? ?
//GO.SORTWK01 DD ?UNIT=2314,SPACE=(TRK,(200,1)),VOL=SER=SORT01 ? ? ?
//GO.SORTWK02 DD ?UNIT=2314,SPACE=(TRK,(200,1)),VOL=SER=SORT02 ? ? ?
//GO.SORTWK03 DD ?UNIT=2314,SPACE=(TRK,(200,1)),VOL=SER=SORT03 ? ? ?
//GO.SORTWK04 DD ?UNIT=2314,SPACE=(TRK,(200,1)),VOL=SER=SORT04 ? ? ?
//GO.SORTWK05 DD ?UNIT=2314,SPACE=(TRK,(200,1)),VOL=SER=SORT05 ? ? ?
//GO.SORTWK06 DD ?UNIT=2314,SPACE=(TRK,(200,1)),VOL=SER=SORT06 ? ? ?
//GO.SYSOUT ? DD SYSOUT=* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
//GO.SYSPRINT DD SYSOUT=* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
//GO.INDD ? ? DD DSN=HERC01.TEST.FILE00XX,DISP=SHR ? ? ? ? ? ? ? ? ?
//GO.OUT1 ? ? DD DSN=HERC01.TEST.FILE00YY,DISP=SHR ? ? ? ? ? ? ? ? ?
IEF244I HERC0101 GO STEP06 - UNABLE TO ALLOCATE 1 UNIT(S) ?
? ? ? ? AT LEAST 1 OFFLINE UNIT(S) NEEDED. ? ? ? ? ? ? ? ? ?
IEF489I HERC0101 - 1 UNIT(S) NEEDED FOR SORTDD ? ? ? ? ? ? ?
IEF247I HERC0101 - 130,137,138,139,13A,13B,13C,13D,13E,13F,2
IEF247I HERC0101 - 232,233,234,235,236,237,238,239,23A,23B,2
IEF247I HERC0101 - 23E,23F,330,331,332,333,334,335,336,337,3
IEF247I HERC0101 - 33A,33B,33C,33D,33E,33F OFFLINE ? ? ? ? ?
01 IEF238D HERC0101 - REPLY DEVICE NAME OR 'CANCEL'. ? ? ? ?
R 01,CANCEL? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
So if you see any obvious corrections feel fre to comment.
----------------------------------------
?
//GO.SORTWK01 DD ?UNIT=2314,SPACE=(TRK,(200,1)),VOL=SER=SORT01? ???
//GO.SORTWK02 DD ?UNIT=2314,SPACE=(TRK,(200,1)),VOL=SER=SORT02? ? ? ? ? ? ???
//GO.SORTWK03 DD ?UNIT=2314,SPACE=(TRK,(200,1)),VOL=SER=SORT03 ? ? ? ? ? ? ??
//GO.SORTWK04 DD ?UNIT=2314,SPACE=(TRK,(200,1)),VOL=SER=SORT04 ? ? ? ? ? ? ??
//GO.SORTWK05 DD ?UNIT=2314,SPACE=(TRK,(200,1)),VOL=SER=SORT05 ? ? ? ? ? ? ??
//GO.SORTWK06 DD ?UNIT=2314,SPACE=(TRK,(200,1)),VOL=SER=SORT06?
//GO.SORTLIB ? ? DD ? DSN=SYS1.SORTLIB,DISP=SHR
When dealing with a PROC (LIKE COBUCG), to supply missing DDNAMES you have to put in the stepname...
Also, MVT COBOL sort routine cannot use extents on a volume, so code a really big value for the primary, cause thats all you'll get.
I THINK that sortlib is right, but you can check it.
|
botongrui, aka ¦Ó¦Òm.
Michael Grom
Jo?o Reginato
Silvio Losa