On Tue, Jun 23, 2020 at 03:41 PM, Drew Derbyshire wrote:

Create a empty dasd loaded 3350, and try to allocate a file via batch.? I can't do an example now, but if you want one later I can.

Just tried it; it works. Here was the .ctl file

drew 3350
vtoc vtoc cyl 2

did a 'dasdload drew.ctl drew.3350'

did this at the Hercules console
attach 721 3350 scratch/drew.3350

did a
m 721,vol=(sl,drew),use=private

Responded with '721' when prompted with
15.59.43 STC 2166? IEF244I MOUNT 721 - UNABLE TO ALLOCATE 1 UNIT(S)??????????????????????????????????????????????????????????????????????????????????
???????? AT LEAST 1 OFFLINE UNIT(S) NEEDED.??????????????????????????????????????????????????????????????????????????????????????????????????????????
15.59.43 STC 2166? IEF489I MOUNT - 1 UNIT(S) NEEDED FOR IEFRDER??????????????????????????????????????????????????????????????????????????????????????
15.59.43 STC 2166? IEF247I MOUNT - 721 OFFLINE???????????????????????????????????????????????????????????????????????????????????????????????????????
15.59.43 STC 2166 *13 IEF238D MOUNT - REPLY DEVICE NAME OR 'CANCEL'.?????????????????????????????????????????????????????????????????????????????????

mount command completed, and I was able to place datasets on volume 'DREW' w/ both RFE and a batch job:

//WEGSCDCC JOB (DOUG,5278),CREATE.FILE,CLASS=A,MSGCLASS=X?????????????? 00000100
//CLEANUP EXEC PGM=IEFBR14????????????????????????????????????????????? 00000200
//CREATE??? DD DSN=DREW.TEST1,DISP=(NEW,CATLG,DELETE),UNIT=3350,??????? 00000300
//???????????? SPACE=(CYL,(50,20),RLSE),VOL=SER=DREW,?????????????????? 00000400
//???????????? DCB=(RECFM=VBS,LRECL=8000,BLKSIZE=16000)???????????????? 00000500

开云体育

On Tue, Jun 23, 2020 at 02:04 PM, Drew Derbyshire wrote:

A problem with DADSLOAD is you can't allocate more files on packs which were DASDLOADed.

What are you seeing that indicates this? I just tried it, had no trouble creating a dataset on a dasdload-ed 3350 that I had mounted.

_._,_._,_

Create a empty dasd loaded 3350, and try to allocate a file via batch.? I can't do an example now, but if you want one later I can.

-- 
Drew Derbyshire

"Ian Stewart. I'm still working for him. To me The Rolling Stones is
 his band. Without his knowledge and organisation... we'd be nowhere."
                                                -- Keith Richards

On Tue, Jun 23, 2020 at 02:04 PM, Drew Derbyshire wrote:

A problem with DADSLOAD is you can't allocate more files on packs which were DASDLOADed.

What are you seeing that indicates this? I just tried it, had no trouble creating a dataset on a dasdload-ed 3350 that I had mounted.

On 6/23/20 11:04 AM, Drew Derbyshire wrote:

On 6/23/20 5:30 AM, Doug Wegscheid wrote:

Thanks for the story; that will be helpful to some poor sod in the future.

I have found that adding SYSCPK to TK3UPD is one of the easiest ways to get the extra compilers, rather than adding them one by one.

I haven't looked for the compilers yet, but I think they mostly there. SYSCPK is on my list.

There are plenty of 3350 addresses in TK3UPD...

*snicker* Been there, got them.? KEW001, KEW002, WYLSRC, WYL001 ...

A problem with DADSLOAD is you can't allocate more files on packs which were DASDLOADed.

No IMON: not present, or not working? I don't recall have to fiddle with it (except possibly adding a PROC so I can start it from the console w/ a dedicated terminal, bypassing TSO, but even that may have already been done).

IMON doesn't work from a TSO command line.? But it DOES work from RPF.

IMON has multiple names is SYS2.CMDLIB, none of which are IMON.

--
Drew Derbyshire

"Do they still play the blues in Chicago
When baseball season rolls around
When the snow melts away,
Do the Cubbies still play
In their ivy-covered burial ground . . ." -- Steve Goodman

On 6/23/20 5:30 AM, Doug Wegscheid wrote:

Thanks for the story; that will be helpful to some poor sod in the future.

I have found that adding SYSCPK to TK3UPD is one of the easiest ways to get the extra compilers, rather than adding them one by one.

I haven't looked for the compilers yet, but I think they mostly there. SYSCPK is on my list.

There are plenty of 3350 addresses in TK3UPD...

*snicker* Been there, got them.? KEW001, KEW002, WYLSRC, WYL001 ...

A problem with DADSLOAD is you can't allocate more files on packs which were DASDLOADed.

No IMON: not present, or not working? I don't recall have to fiddle with it (except possibly adding a PROC so I can start it from the console w/ a dedicated terminal, bypassing TSO, but even that may have already been done).

IMON doesn't work from a TSO command line.? But it DOES work from RPF.

I didn't worry about it because I knew it had been updated since TK3UPD was packaged and so I knew I needed to reinstall it.

-ahd-

--
Drew Derbyshire

Q. What machine does Windows Vista run best on?
A. A 35 mm slide projector.

开云体育

Working as designed.

AKA: The stupid user (me) rides again.? :-)

In the 'good' trace, pr3287 is connected, waiting for the host to send data.

In the 'bad' trace, pr3287 connects, the host breaks the connection, pr3287 waits five seconds and tries again, forever.

So when x3270 connects with a bad group, the following is a server (Hercules) side message reported (which pr3287 does not seem to receive):

>? Connection rejected, no available 3270 devices in the xxx group

I think part of my problem is that it doesn't probably need a -reconnect for a valid configuration; the printer won't drop after each job.? Without the reconnect, it would not tweak Hercules multiple times.

The basic TN3270 protocol does not allow the host to send any sort of diagnostic saying why the session was disconnected; it just disconnects. With the time delay, the net load on the workstation and the host for this is diminishingly small.

Well, the host is being acting hammered.? Trust me. ?

Is there some other behavior you would prefer?

I'd like the host to not act hammered.? Not pr3287's fault.?

I would like the same clear message to be sent to the printer.

-ahd-

-- 
Drew Derbyshire

Mobile: 425-471-8183

"Go ahead, make my day." -- "Sudden Impact"

Thanks for the story; that will be helpful to some poor sod in the future.

I have found that adding SYSCPK to TK3UPD is one of the easiest ways to get the extra compilers, rather than adding them one by one. There are plenty of 3350 addresses in TK3UPD...

No IMON: not present, or not working? I don't recall have to fiddle with it (except possibly adding a PROC so I can start it from the console w/ a dedicated terminal, bypassing TSO, but even that may have already been done).

开云体育

(bcc: Paul Mattes so he can whack pr3287. "Paging Paul Mattes" ...)

I've got MVS 3.8 up at the TK3 UPD level humming. I have QUEUE and RPF updated and SPY working. (I don't have IMON yet). WATFIV is there. JRP is running (doing nothing), and I've migrated my personal files from my bastard system TK3.

Silly me, I got fancy and tweaked things ...

... and performance went completely to hell. Utterly. So bad I spent Saturday evening writing a SUBMIT EXEC to submit jobs from my 4361 VM test system to MVS because I couldn't stand the 4 seconds or worse just to close the editor under MVS.

I could not. tell. why.

I blamed shared spool, I blamed my cats, I blamed everything. So I simplified. I ripped things out, one by one. And finally, I found it.

What I had done is connect a 3287 printer for use with JRP via the command:

 pr3287 -reconnect -command cat -V PRT@hercules:3278

This was correct, but I had no PRT label on my 3287 devices in hercules.conf. x3270 bails on this problem with a no device available error, but it seems pr3287 trundles along and connects to any old device. Hercules and pr3287 do NOT play well after this.

(It was Hercules with the issue, not VTAM or JRP. Neither were shown to be taking CPU in QUEUE.)

After correcting the devices in hercules.conf and restarting ... the biblical performance issue went away.

-ahd-

p.s. VM TCP/IP RXSOCKET wonks, ping me offline for my RXSOCKET EXECs HOST, HOSTNAME, and SUBMIT.? If nothing else, they are test fodder for your VM/370 R6 implementation of RXSOCKET.

-- 
Drew Derbyshire

"We haven't been properly introduced. I'm Buffy, and you're history."
                                    -- "Buffy the Vampire Slayer"

Yet another update:

6. The SYS1.PARMLB(SNAACT) member has to be modified to handle the new terminal. Byt why doesn't my changes have any effect - still uknown.

This turned out to be a completely different file responsible for this, the SYS1.PARMLIB(STARTSTD). Removing references to the now removed terminals solved the problem, also adding the one terminal that I wanted to have in my system, the N07L21. Haven't figured out the use for SNAACT and SNAINACT, really though.

7. It is possible to run the command from SNAACT in the console. V NET,ACT,ID=N07L21,LOGON=SNASOL,LOGMODE=MHP3278E (choose whatever ID in your setup)
8. Login works fine, but for some reason logoff and doing the subsequent disconnect of the TN3270 client make the PU fail! Why? Still researching that. Possibly related to 7? Or a problem in comm3705?

Chatted with Max Parke over mail and he suggested that making a few functions inside the comm3705 module into dummies would solve it and it indeed worked fine. So no more crashes when disconnecting the TN3270.

I have written a more in-depth article here :?

Started to look at simple SDLC implementation to run in the STM32 chip to be able to bridge to SDLC. First thing is to get it to send just a SNRM frame to the Informer 213 terminal and see what it responds.
Interfacing the STM32 gadget to Hercules will either require patches to the comm3705 module or possible a new comm3704 module that just focus on connecting to real terminals, being it BSC or SDLC.

/Mattis

开云体育

Am 22.06.2020 um 05:12 schrieb Drew Derbyshire <swhobbit@...>

I found what job installed it (MVS0130 on the original TK3 CD). Seeing what that job renamed, I knew what to rename back & what to delete.

How about a short summary for making it easier to others searching for this information? Thanks!

Where's the fun in THAT?? My two line description...?

Delete the imposters.? I had a custom program (I wrote it recently, in 1983) handy, you'll probably want IEHPROGM:

//AHDELMEM JOB AHD,A.H.DERBYSHIRE,
//        CLASS=S,
//        MSGCLASS=R,
//        NOTIFY=AHD
/*JOBPARM ROOM=TSO,LINES=300
//*
//DROP    EXEC PGM=DELETMEM
//STEPLIB  DD DSN=AHD.UTILITY.LINKLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSLIB   DD DSN=SYS2.CMDLIB,DISP=SHR
//SYSIN    DD *
-DLM H
-DLM HELP
//

Rename the archived members back to their real names:

//AHDRHELP JOB AHD,DERBYSHIRE-IEBUPDATE,CLASS=A,
//             MSGCLASS=R,
//             NOTIFY=AHD
//RENAME  EXEC PGM=IEHPROGM
//SYSPRINT DD  SYSOUT=*
//MVSRES   DD  DISP=OLD,UNIT=3350,VOL=SER=MVSRES
//SYSIN    DD  *
 RENAME DSNAME=SYS1.CMDLIB,VOL=3350=MVSRES,MEMBER=OLDH,NEWNAME=H
 RENAME DSNAME=SYS1.CMDLIB,VOL=3350=MVSRES,MEMBER=OLDHELP,NEWNAME=HELP

-- 
Drew Derbyshire

 The less you bother me the sooner you'll get results

Hello Drew,

Am 22.06.2020 um 05:12 schrieb Drew Derbyshire <swhobbit@...>:

I found what job installed it (MVS0130 on the original TK3 CD). Seeing what that job renamed, I knew what to rename back & what to delete.

How about a short summary for making it easier to others searching for this information? Thanks!

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE -

On 6/21/20 12:38 PM, Drew Derbyshire wrote:

Is there a stock job to disable the full screen HELP on a MVS Turnkey system?

(I'm amazing it ever got installed, seeing as how it dumps unformatted text, and I think it suppresses error messages.)

I found what job installed it (MVS0130 on the original TK3 CD). Seeing what that job renamed, I knew what to rename back & what to delete.

-ahd-


--
Drew Derbyshire

Mobile: 425-471-8183

"Bugs Bunny was an optimist."

Is there a stock job to disable the full screen HELP on a MVS Turnkey system?

(I'm amazing it ever got installed, seeing as how it dumps unformatted text, and I think it suppresses error messages.)

-ahd-

--
Drew Derbyshire

Mobile: 425-471-8183

"If you feed [UUPC for the Mac] after midnight, and it gets nasty and
shreds your living room furniture, that's your problem, not mine. ;-)"
-- Dave Platt

--

开云体育

Another solution is to use XMIT manager, perhaps it works under wine...

hth
搁别苍é

_._,_._,_

---

Yes - using Codeweavers CrossOver-Office which (if you haven't met it before) uses a late version of wine to package Win apps), runs the EXE successfully. I tested with a few of the supplied XMIT file samples and it seemed to do everything. The EXE does not get installed but a launcher can be created by the GUI which bypasses that. I am using Linux Mint 19,3 but COO runs on most Linux versions I believe.

Very useful - thanks 搁别苍é

Bill

开云体育

so then the next "problems" are knowing how many records the XMI is, and knowing how many directory blocks to use. UNXMIT can tell me both of those, but was there a way to do this inside MVS?

I suppose just looking at the size for the XMI should get you close for how much to allocate overall? REVIEW tells me that my XMI took 515 tracks of 3350 blocked at 5600 (it was unloaded from a 3390, where the PDS had a block size of 5600), the output of RECV370 was 479 tracks on a 3350, so within 10%.

Still need to make 2 passes (or look at the file with UNXMIT) to determine # of directory blocks to allocate. ? UNXMIT said the original file had 30 directory blocks (on a 3390), I only needed 25 on a 3350, so original was probably overallocated?? ?????

I think directory blocks are fixed size (256 bytes as I dimly recall from 1985), so device type won't matter.? (Checks source? of program I wrote then ... yup, 256 byte input buffer.)

Scanning the file for the size and then allocating via blocks with a secondary allocation for under allocation mistakes (and of of course RLSE) should be fine if you won't be updating the file much.?

This may be a case if don't let "best" be the enemy of "good enough".

-ahd-

-- 
Drew Derbyshire

"I never thought much of Pat Buchanan until I heard one of his speeches
 in the original German."                       -- Molly Ivins

Another solution is to use XMIT manager, perhaps it works under wine...

hth
搁别苍é

On Fri, 19 Jun 2020, Jim Morrison wrote:

On 6/19/20 4:34 AM, Giuseppe Vitillaro wrote:

I had similar experiences with the 00.06 version of XMIT370/RECV370.
If I got the logic correctly, I doubt I did, when XMIT370 has
a PDS dataset as its input SYSUT1 dataset, it run IEBCOPY to create a SYSUT2 RECFM=VS dataset over a dasd on the source system and then PACK such dataset into its XMITOUT (RECFM=FB,LRECL=80) dataset.

Yep, exactly so. The "IEBCOPY unload" dataset (output of IEBCOPY) contains info about the original dataset. I'll just assume you have the DDNAMEs correct.

Neither XMIT370, neither the driving JCL, have any control over
the IEBCOPY DCB for the XMIT370 SYSUT2 dataset. I guess IEBCOPY choose
a DCB=(RECFM=VS,LRECL=X,BLKSIZE=Y) suitable for the dasd where the SYSUT2 dataset is stored and XMIT370 store such DCB into its XMITOUT sequential dataset control records.

I mildly lean toward saying IEBCOPY always picks the same RECFM, LRECL, and BLKSIZE but I don't remember what. You're probably right about what the XMIT contains in reference to the "IEBCOPY unload" dataset but it's been too long for me to be sure.

When the XMITOUT (RECFM=FB,LRECL=80) dataset is given as the
XMITIN input dataset to RECV370 on the target system, RECV370,
as the very first thing it does, try to UNPACK XMITIN to its SYSUT1,
as a (RECFM=VS,LRECL=X,BLKSIZE=Y) IEBCOPY dataset, reading the
control records, to match the original IEBCOPY dataset, on a, possibly different, target dasd.

Yep, it "unwraps" the XMIT from around the "IEBCOPY unload" dataset and recreates the "IEBCOPY unload" dataset using the attributes IEBCOPY assigned.

Something weird may happen when the source dasd and the target
dasd doesn't match, this information, for what I can understand
is not stored into the XMITOUT dataset, and RECV370 abend.

Yes, I believe that info about the original dataset is stored in the "IEBCOPY unload" dataset. I don't remember what RECV370 shows, but `recv390 +xmisum abc.XMI` will give you some XMITIN info. Unfortunately not the device type, altho I think it's in the the data. I might not have cared about knowing what dasd device type the original data came from, as I already knew if it was on my system.

If you want info on the "IEBCOPY unload" dataset, it's probably still hanging around after XMIT370 is done, just check the dataset.

I think I may have decided to continue with the restoration of the original dataset, under the premise that at least producing something was better than nothing. Doping so certainly provided debugging info when I needed it.

As I began writing RECV370, there were a lot of things about the XMIT and "IEBCOPY unload" datasets I didn't understand. RECV370 is as much a research tool as a dataset restorer. Hence the tons of diagnostic data it can provide.

I would be glad to ear comments about this picture.
It is probably wrong, but I haven't found any other way
to explain why sometime RECV370 abend on some XMIT dataset.
Peppe.

Pretty well deduced.

Jim

Thanks for your comments, Jim, really appreciated!

About IEBCOPY unloaded datasets DCB, reading the IBM
Utility Manual for OS/VS2, Release 3.8, GC26-3902-1 (September 1983)
page 6-1 (PDF page 77), it looks the DCB logic is quite involved:

-----
An unload data set is always a variable spanned record format with sequential organization, (RECFM=VS and DSORG=PS).

The block size for unloaded data sets is determined as follows:

1. The minimum block size for the unloaded data set is calculated as being equal to the larger of:
284 bytes, or
16 bytes + the block size and key length of the input data set.

2. If a user-supplied block size was specified, and it is larger than the minimum size calculated in step 1 (above), it will be passed to step 3 (below). Otherwise, the minimum size is passed.

3. The block size value passed from step 2 (above) is then compared with the largest block size acceptable to the output device. If the output device capacity is less than the block size passed in step 2, the unloaded data set block size is set to the maximum allowed for the output device.

4. The logical record length (LRECL) is then set to the block size minus four (4) bytes.
------

and, of course, it is quite the same after almost forty years:



The abend problem we face, I think, arise from this statement at point 3:

If the output device capacity is less than the block size passed in
step 2, the unloaded data set block size is set to the maximum allowed
for the output device.

From my IEBCOPY tests, I still have around, this
is exactly what happens, LRECL depends from the BLKSIZE of the input PDS, while BLKSIZE from LRECL and the maximum block size allowed on the output dasd.

For example, for the same fixed input PDS

DCB=(RECFM=FB,LRECL=80,BLKSIZE=19040) stored on a 3390

I get these IEBCOPY unloaded datasets DCB:

RECFM=VS,LRECL=19056,BLKSIZE=19060 on a 3390 output dasd
RECFM=VS,LRECL=19056,BLKSIZE=7294 on a 2314 output dasd

So it looks the IEBCOPY output unloaded dataset LRECL is FIXED and depends
only from the input PDS dataset BLKSIZE, while the IEBCOPY output unloaded
dataset BLKSIZE depends from the MAXIMUM block size allowed
on the output dasd, BLKSIZE=7294 for a 2314 in this example,
once LRECL has been computed.

I bet RECFM=VS had been choosed by IBM, for IEBCOPY unload datasets, just for this reason, to let IEBCOPY to pick
a suitable value for LRECL, possibly greater than the BLKSIZE,
on an output dasd which can't store larger block sizes.

Once IEBCOPY choose the DCB, for an output dasd, for what I can
understand, the game is over, it can't be changed anymore, changing
the BLKSIZE would make IEBCOPY unable to read and restore the
unloaded dataset. And IEBCOPY "force" the choosed DCB at OPEN
time for its unloading dataset, I think, it can be changed
specifying a user DCB in the driving JCL, it get overidden
by the DCB IEBCOPY built at runtime.

So, the only thing RECV370 can do, unpacking an XMIT dataset,
is trying to restore an IEBCOPY unloaded dataset with the original
DCB, otherwise IEBCOPY would be unable to perform its job.

On a modern Z/OS, basically only 3390 dasds are around,
this is barely a problem, but on our beloved MVS3.8j, it
is quite easy to get trapped trying to restore a PDS originally
stored on a 3390, with a large BLKSIZE, into an output IEBCOPY
SYSUT1 unloaded dataset which can't accomodate such a large
BLKSIZE.

As easy as choosing UNIT=SYSDA or UNIT=SYSALLDA for
RECV370 SYSUT1 DDNAME, even if the RECV370 SYSUT2 UNIT
is for a correct output dasd, which can store the BLKSIZE
of the restored PDS.

For this reason, I guess, choosing UNIT=3390, as Jay Moseley
suggested, on a RECV370 job, for SYSUT1, solve the problem, a 3390
may host the largest possible BLKSIZE, if I got the picture.

Just a question, if I can Jim.

Would be possible to check for this particular case
in the RECV370 code logic and output an error asking
for a suitable SYSUT1 UNIT before even attempting
to unpack an XMIT dataset with IEBCOPY?

I understand is quite easy to get the mistake, with
a clear picture of this problem, but, for naive users,
like me, it may be a nightmare to debug from an abend ;-)

What we get is:

10.02.58 JOB 1857 $HASP373 XX1R STARTED - INIT 1 - CLASS A - SYS SYS2
10.02.58 JOB 1857 IEF403I XX1R - STARTED - TIME=10.02.58
10.02.59 JOB 1857 IEC036I 002-0C,IGC0005E,XX1R,RECV,SYSUT1,121,SORTW2,
10.02.59 JOB 1857 IEC036I SYS20172.T100258.RA000.XX1R.SYSUT1
10.02.59 JOB 1857 IEC999I IFG0TC0A,IFG0TC0B,XX1R ,RECV ,DEB ADDR = A1D034
10.02.59 JOB 1857 IEC999I IFG0TC0A,IFG0TC0B,XX1R ,RECV ,DEB ADDR = A1D0E4
10.02.59 JOB 1857 IEF450I XX1R RECV - ABEND SC03 U0000 - TIME=10.02.59
10.02.59 JOB 1857 IEFACTRT - Stepname Procstep Program Retcode
10.02.59 JOB 1857 XX1R RECV RECV370 AB SC03
10.02.59 JOB 1857 IEF404I XX1R - ENDED - TIME=10.02.59
10.02.59 JOB 1857 $HASP395 XX1R ENDED

RECV370 v00.06 Copyright 2002-2008 James M. Morrison
RECV370 may be distributed under the terms of the Q Public License version 1.0
RECV370 Initial Developer James M. Morrison
RECV370 ABENDed

from a RECV370 job I just run over one of the SORTWn 2314 dasd I've
online on my Moseley sysgen, which perfectly run over a 3390 UNIT.

Thanks again for your time, Peppe.